process data for session info display

[totaam]

Issue migrated from trac ticket # 1702

component: core | priority: minor | resolution: fixed | keywords: PID htop

2017-11-24 16:29:22: Boruch created the issue

---

It would be nice for the "session information" menu item of the system tray to display information about the processes related to that session, something either similar to htop or pstree, but restricted to processes of that session.

An advantage of some form of htop tab would be an ability to send a signal to a process within the session, without the risk of confusing it with an identical program running in another xpra session.

[totaam]

2017-11-24 16:41:29: antoine changed status from new to assigned

[totaam]

2017-11-24 16:41:29: antoine changed component from android to core

[totaam]

2017-11-24 16:41:29: antoine commented

---

How would we identify the processes to display here?

• just the ones we manage with start / start-child and friends?
• or just the ones that have windows and a valid NET_WM_PID?
• or both

We could offer different actions for each process:

• send signal
• close windows (if any)
• raise windows (if any)
  etc..

Some more work in this area is already planned: #1671

[totaam]

2017-11-24 20:13:57: Boruch commented

---

I think what would cover everything would be

htop -p \
  $(for aa in $(pgrep xpra); do pstree -np $aa; done \
    | sed -n 's/^[^(]*_;s/)[^(]*(/,/g;s/)$_;H;$x;s/\(.\)\n/\1,/gp')

Let me know if the one-liner doesn't work for you. I had to split it over three lines in the comment box in order for it to line-break properly and sometimes the re-formatting messes things up.

[totaam]

2017-12-21 08:02:07: antoine uploaded file server-commands-window.png (30.5 KiB)

what the new server commands dialog looks like

[totaam]

2017-12-21 08:03:59: antoine changed status from assigned to new

[totaam]

2017-12-21 08:03:59: antoine changed owner from antoine to Boruch

[totaam]

2017-12-21 08:03:59: antoine commented

---

Implemented in:

• r17701 + r17704: show start commands and their status
• r17705 + r17709: send a signal with a click of a button

The end result looks like this:
[[Image(server-commands-window.png)]]

We could add more to it, like adding "raise all windows", "minimize all windows" or "close all windows" for each pid, etc.

@boruch: please close if that works for you.

[totaam]

2018-01-03 04:06:56: Boruch commented

---

Using version 17795, I just now tried this feature:

1] It took a while for me to find where in the menu it was placed. My vote is to rename the menu entry something like "Send signals".

2] I'll try to upload a screenshot of my test, useful for several of the following feedback items. The screenshot shows four xpra windows, :4 - :7, running the thunar file manager, two xfce4-terminals, and one xclock. In the center is a single signal window for :4, serving the thunar process.

3] The window is difficult for me to read. It displays as off-white text against a white background. My guess is that's because my gtk2/gtk3/qt themes are all light foreground against dark background, and that xpra is picking up only my foreground color.

4] The icon for the thunar application does not appear in the server command window. Note that an icon does appear in the system tray, although curiously, it is a trash icon!

5] The window displays a second process, "/etc/X11/xsession true" with an exit code of 127. Why?

6] Sending the thunar process a SIGINT, did not kill the process (as it does when performed from the command line). Sending a SIGKILL does update the window to place a -9 in the "exit code" column, and removes the ability to send further signals to the process; however, the process window remains open, running xpra list shows the instance is alive, and the program still operates.

7] Attempting to open a server command window fails for any of the other three xpra instances. The STDOUT at the command line is:

$Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py", line 286, in show_server_commands
    self.server_commands = getServerCommandsWindow(self)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/server_commands.py", line 36, in getServerCommandsWindow
    _instance = ServerCommandsWindow(client)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/server_commands.py", line 72, in __init__
    if self.client.server_start_new_commands:
AttributeError: 'XpraClient' object has no attribute 'server_start_new_commands'

8] The screenshot you posted above includes a button labeled "start new" which does not appear for me.

9] Manually closing the :4 thunar instance of xpra does not change the inability of other instances to display their "server command" windows.

10] Other windows of the other xpra instances do appear (eg. information > session info).

[totaam]

2018-01-03 04:08:24: Boruch uploaded file 2018-01-02-223606_1366x768_scrot.png (55.3 KiB)

[totaam]

2018-01-03 04:16:40: Boruch changed owner from Boruch to Antoine

[totaam]

2018-01-03 06:23:30: antoine commented

---

1] It took a while for me to find where in the menu it was placed. My vote is to rename the menu entry something like "Send signals".
This dialog will be expanded to do more than just send signals.

3] The window is difficult for me to read. It displays as off-white text against a white background. My guess is that's because my gtk2/gtk3/qt themes are all light foreground against dark background, and that xpra is picking up only my foreground color.
There was a reason for that, but I can't find it in the changelogs (IIRC, it looked bad on some platforms, maybe win32), so r17834 removes the background color override, at least for now.

4] The icon for the thunar application does not appear in the server command window. Note that an icon does appear in the system tray, although curiously, it is a trash icon!
Works fine here with Fedora 27, please provide the full distro and package versions so that I can reproduce. I did see this warning in the thunar output, so maybe thunar is doing something wrong:

(thunar:13840): Gdk-WARNING **: gdk_window_set_icon_list: icons too large

5] The window displays a second process, "/etc/X11/xsession true" with an exit code of 127. Why?
You must be using some sort of Debian distro and you have remnants of their configuration files.
We do not ship this setting but they do.
See /etc/xpra/conf.d/60_server.conf (or maybe even /etc/xpra/xpra.conf if the version you had installed was very old)

6] Sending the thunar process a SIGINT, did not kill the process (as it does when performed from the command line). Sending a SIGKILL does update the window to place a -9 in the "exit code" column, and removes the ability to send further signals to the process; however, the process window remains open, running xpra list shows the instance is alive, and the program still operates.
If you cannot send any more signals then the process has terminated and an exit code is probably shown in the window. (you can verify since the pid should still be shown)
It may be that thunar is spawning a new process, we're killing the one we started but we have no easy way of knowing about the other ones (we could look at the list of pids from the windows we forward - but there are security issues with that).

7] Attempting to open a server command window fails for any of the other three xpra instances. The STDOUT at the command line is:
How do I reproduce this?
The stacktrace looks bogus, if that was a bug then you would never had been able to bring up this window.
How do I reproduce it?

8] The screenshot you posted above includes a button labeled "start new" which does not appear for me.
You must enable start-new-commands=yes on your server. (disabled by default)

9] Manually closing the :4 thunar instance of xpra does not change the inability of other instances to display their "server command" windows.
10] Other windows of the other xpra instances do appear (eg. information > session info).
I don't really understand these last two items.

[totaam]

2018-01-03 12:33:49: Boruch commented

---

Replying to [comment:6 Antoine Martin]:

This dialog will be expanded to do more than just send signals.

... eg. renice?

4] The icon for the thunar application does not appear in the server command window. Note that an icon does appear in the system tray, although curiously, it is a trash icon!
Works fine here with Fedora 27, please provide the full distro and package versions so that I can reproduce.

Linux 4.14.0-1-amd64 #1 SMP Debian 4.14.2-1 (2017-11-30) x86_64 GNU/Linu
Thunar  1.6.3-2 (Xfce 4.10)
i3-wm 4.14.1-1

I did see this warning in the thunar output, so maybe thunar is doing something wrong:

(thunar:13840): Gdk-WARNING **: gdk_window_set_icon_list: icons too large

4.1] I'm not getting that Gdk warning when running thunar either within xpra or directly, though I recognize it from other contexts.

4.2] What I reported about the appearance of the trash icon turned out to be because the trash directory had been selected within thunar. When another directory is selected, the expected icon does appear on the system tray. However...

4.3] No icon appears appears for me in the 'server commands' window. This is the case with xfce4-terminal as well as with thunar.

5] The window displays a second process, "/etc/X11/xsession true" with an exit code of 127. Why?
You must be using some sort of Debian distro and you have remnants of their configuration files.
We do not ship this setting but they do.
See /etc/xpra/conf.d/60_server.conf (or maybe even /etc/xpra/xpra.conf if the version you had installed was very old)

Yes, I had originally installed xpra from the debian repository, which would be version 0.17.6. My /etc/xpra/xpra.conf file does include that line uncommented, and my /etc/xpra/conf.d/60_server.conf file does include that line, but commented out.

6] Sending the thunar process a SIGINT, did not kill the process (as it does when performed from the command line). Sending a SIGKILL does update the window to place a -9 in the "exit code" column, and removes the ability to send further signals to the process; however, the process window remains open, running xpra list shows the instance is alive, and the program still operates.
If you cannot send any more signals then the process has terminated and an exit code is probably shown in the window. (you can verify since the pid should still be shown)
It may be that thunar is spawning a new process, we're killing the one we started but we have no easy way of knowing about the other ones (we could look at the list of pids from the windows we forward - but there are security issues with that).

After some checking, what seems to be happening is that the xpra "server commands" window is showing the parent PID of the program called with xpra start --start=, which for the cases of thunar and xfce4-terminal, is a shell sh, with a PID value numerically one less than that of the program. It seems xpra spawns a shell which forks and then disowns the requested program.

7] Attempting to open a server command window fails for any of the other three xpra instances. The STDOUT at the command line is:
How do I reproduce this?
The stacktrace looks bogus, if that was a bug then you would never had been able to bring up this window.
How do I reproduce it?

Well, now that you ask, I can't reproduce it... Will try again when I have time later today.

9] Manually closing the :4 thunar instance of xpra does not change the
inability of other instances to display their "server command" windows.
10] Other windows of the other xpra instances do appear (eg. information > session info).
I don't really understand these last two items.

They were in continuation of (7). What I meant was that when I had xpra instances on :4 - :7 and wasn't able to get the "server commands" window to appear for :5 - :7, stopping instance :4 did not change the situation, and that for instances :5 - :7 other windows of the xpra system tray menu GUI did appear. All that is moot if I can't reproduce the issue...

[totaam]

2018-01-04 07:22:20: Boruch commented

---

I haven't been able to reproduce item 7 above, but item 6 is reliably reproducable for the three gui programs that I tried: xclock, thunar, and xfce4-terminal

[totaam]

2018-01-04 07:45:16: antoine changed owner from Antoine to Boruch

[totaam]

2018-01-04 07:45:16: antoine commented

---

This dialog will be expanded to do more than just send signals.
... eg. renice?
Could do. Was thinking more in terms of minimizing all windows, raising, controlling the screen refresh rate / bandwidth budget on a per-application basis, etc.

4.3] No icon appears appears for me in the 'server commands' window. This is the case with xfce4-terminal as well as with thunar.
Weird, the parent pid thing (see below) would have caused this, but I didn't hit it somehow.
If you still have the problem with the latest builds, please post the "-d util" command output captured just when the "server-commands" window is being shown.

My /etc/xpra/xpra.conf file does include that line uncommented..
The updated package should have overwritten this file.
There may be other settings in there that aren't quite right, or no longer applicable.

After some checking, what seems to be happening is that the xpra "server commands" window is showing the parent PID of the program..
We used to wrap all commands in a shell except when already using a wrapper like vglrun using the exec-wrapper option (see r12175), I've removed the shell in r17862 + r17863. We'll see if anything breaks.

It seems xpra spawns a shell which forks and then disowns the requested program
It didn't disown it. ie: for "xterm -ls" we were running "sh" "xterm -ls". (now just "xterm" "ls")

I haven't been able to reproduce item 7 above
OK

[totaam]

2018-01-30 16:24:01: antoine changed owner from Boruch to maxmylyn

[totaam]

2018-01-30 16:24:01: antoine commented

---

@maxmylyn: FYI, feel free to close.

[totaam]

2018-02-01 20:13:31: maxmylyn changed status from new to closed

[totaam]

2018-02-01 20:13:31: maxmylyn set resolution to fixed

[totaam]

2018-02-01 20:13:31: maxmylyn commented

---

Noted and closing.