How to get a specific PID #

[rikona]

Thursday, December 31, 2015, 12:48:57 AM, Ralf wrote:

> On Wed, 30 Dec 2015 19:06:58 -0800, rikona wrote:
>>Wednesday, December 30, 2015, 1:14:53 PM, Ralf wrote:
>>
>>> On Wed, 30 Dec 2015 21:57:24 +0100, I wrote:  
>>>>On Wed, 30 Dec 2015 22:20:28 +0200, Amichai Rotman wrote:   
>>>>>Just use the 't' key to switch htop to 'tree mode'.    
>>>>
>>>>How does this show what xfw window belongs to what PID?
>>>>
>>>>  1  [||                                        2.8%]     Tasks: 59,
>>>> 83 thr; 1 running 2  [|||
>>>> 4.2%]     Load average: 0.03 0.04 0.05
>>>> Mem[||||||||||||||||||||||||||||||||||||840/3704MB]     Uptime: 2
>>>> days, 21:45:15 Swp[|                                    19/4706MB]
>>>>
>>>>  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+
>>>> Command 7665 rocketmou  20   0  123M 14020 11652 S  0.0  0.4
>>>> 0:00.19 ├─ xfw 7663 rocketmou  20   0  123M 13960 11592 S  0.0
>>>> 0.4  0:00.14 ├─ xfw  
>>
>>> By the following example you can see, when using wmctrl I can see
>>> what instance of pluma, IOW what window, belongs to what PID, but
>>> for xfw the PIDs aren't displayed correctly. As shown by an earlier
>>> reply, even if window title bars should share the same name, it's
>>> possible to change the name with wmctrl, but this only makes sense,
>>> if it also displays the PID.  
>>
>>> $ ps aux|grep -v grep|grep xfw
>>> rocketm+ 28733  0.2  0.3 126964 13836 pts/4    S+   14:25   0:00 xfw
>>> root     28734  0.0  0.1  72312  5216 pts/3    S+   14:26   0:00
>>> sudo xfw root     28735  0.2  0.3 127744 14220 pts/3    S+   14:26
>>> 0:00 xfw $ ps aux|grep -v grep|grep pluma
>>> rocketm+ 28736  4.0  1.0 625936 40996 pts/2    Sl+  14:26   0:03
>>> pluma root     28741  0.0  0.1  72312  5112 pts/1    S+   14:26
>>> 0:00 sudo pluma root     28742  3.1  0.8 991168 32152 pts/1    Sl+
>>> 14:26   0:01 pluma $ wmctrl -lp
>>> 0x00a00003 -1 25836  archlinux panel
>>> 0x00e0001d -1 25835  archlinux panel
>>> 0x00800007  0 28670  archlinux rocketmouse at archlinux:~
>>> 0x014004be  0 0            N/A .jackdrc - /home/rocketmouse
>>> 0x018004bf  0 0            N/A .bashrc - /root
>>> 0x01a00114  0 28736  archlinux .jackdrc (~) - Pluma
>>> 0x01c00110  0 28742  archlinux .bashrc (~) - Pluma  
>>
>>
>>wmctrl -lp does display the title bar BUT the PIDs in wmctrl are
>>different from *most* of what is given by top, so it's a bit more
>>difficult to get the correct PID to kill.
>>
>>Top lists many more PIDs than wmctrl - it seems that each tab in kate
>>has a different PID - this seems to account for the difference in the
>># of PIDs displayed. Other pgms display multiple tabs in a window that
>>has only one PID, so different pgms work in different ways.

> You seem not to understand what I explained, from all the things
> explained by this thread wmctrl is the only way to get the PID that
> belongs to a window.

I understand and agree - it does give me a PID, as I noted.

> wmctrl gives information about all windows, including the PID of the
> program using this window, but it does not give information about all
> the other programs that are running.

I agree - I added some additional info because my initial look at PIDs
in wmctrl showed DIFFERENT #s from those in htop. You had mentioned
that wmctrl did not show the PIDs correctly, which is also mentioned
in the wmctrl --help, and I wanted to show that it does give the right
PIDs for kate/Ubuntu12.4.

'Other programs' can include (1) tabs in kate, which are added pgms
each of which has its own PID, and DO NOT show up in wmctrl, and (2)
non-kate pgms which may have several tabs but only one PID - the tabs
being handled within one pgm/PID. I wanted to mention both cases to
help clarify what was going on re multiple PIDs.

> top, htop, atop, ps aux gives information about all programs running,
> but not about what program runs in what window.

Agreed.

>>If I look in htop in tree mode it looks as though the extra tabs are
>>listed as children to the main window PID. It looks like wmctrl
>>displays only one PID for the kate 'window' which actually contains
>>multiple PIDs. But, the # displayed IS the parent window PID, so this
>>can give me the PID I need to kill the window.

> You never mentioned that you want to exit a tab,

That's because I never wanted to exit a tab - I'd prefer to KEEP the
info.

> you claimed you run several windows of kate and want to close a
> window.

I had to close a 'window' because I had no other apparent
choice.

>>If I do kill the 'parent' kate PID, would that also kill the children
>>kate PIDs? If it would, is there a way to keep AND access the
>>children, and just kill the parent? And, if I kill a children window,
>>will that also kill the parent?

> Why don't you simply start a new instance (window) of kate and open
> a few tabs, all old PIDs do not change, so the new PIDs are all
> related to the new Kate Window and it's tabs. With wmctrl check the
> PID of the window, then kill just the PID of a tab for testing
> purpose. This would have no impact to your other Kate windows and
> you could do tests.

I was considering doing this, but thought folks here might already
know the answer, and perhaps more info that may be significant.

> Btw. whgy didn't you simply kill all Kate instances in the meantime
> and reopened them again?

I may have 30-50 documents open, in various states of progress, some
saved, others not yet because not finished, from a few different
media. I'd have to go through them all and was looking for a simpler
solution. That's why I'd still like to be able to keep access to the
orphan kate tabs/pgms if possible.

> On Wed, 30 Dec 2015 19:07:32 -0800, rikona wrote:
>>Tuesday, December 29, 2015, 9:02:30 PM, Keith wrote:
>>> You can use the command: xkill
>>Does this work at a 'window' level?

> I doubt that a GUI tool is able to select a tab of a window that isn't
> responsive, IOW if xkill should work, then it most likely would kill
> the complete window.

> However, I also doubt that killing the PID of a tab by command line
> will make the windows with the rest of the tabs responsive again.

My thought too, but I was hoping to be able to still access the
tabs/pgms if the parent window is closed...

> On Wed, 30 Dec 2015 21:13:41 -0800, Keith wrote:
>>Yes this works at the window level. All instances of kate that are
>>running will be killed when you use xkill so save your work in other
>>windows first.

> With "instances" you mean tabs, but assumed you run two or more windows
> of Kate, then it would just kill one window, right?

-- 

 rikona