xpra icon
Bug tracker and wiki

Opened 8 weeks ago

Last modified 2 weeks ago

#1702 new enhancement

process data for session info display

Reported by: Boruch Owned by: Boruch
Priority: minor Milestone: 2.3
Component: core Version: trunk
Keywords: PID htop Cc:

Description

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.

Attachments (2)

server-commands-window.png (30.5 KB) - added by Antoine Martin 4 weeks ago.
what the new server commands dialog looks like
2018-01-02-223606_1366x768_scrot.png (55.3 KB) - added by Boruch 2 weeks ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 weeks ago by Antoine Martin

Component: androidcore
Milestone: 2.22.3
Status: newassigned

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

comment:2 Changed 8 weeks ago by Boruch

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.

Changed 4 weeks ago by Antoine Martin

Attachment: server-commands-window.png added

what the new server commands dialog looks like

comment:3 Changed 4 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to Boruch
Status: assignednew

Implemented in:

The end result looks like this:
what the new server commands dialog looks like

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.

comment:4 Changed 2 weeks ago by Boruch

Using version r17795, 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).

Last edited 2 weeks ago by Antoine Martin (previous) (diff)

Changed 2 weeks ago by Boruch

comment:5 Changed 2 weeks ago by Boruch

Owner: changed from Boruch to Antoine

comment:6 Changed 2 weeks ago by Antoine Martin

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.

comment:7 in reply to:  6 Changed 2 weeks ago by Boruch

Replying to 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...

Last edited 2 weeks ago by Antoine Martin (previous) (diff)

comment:8 Changed 2 weeks ago by Boruch

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

comment:9 Changed 2 weeks ago by Antoine Martin

Owner: changed from Antoine to Boruch

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

Note: See TracTickets for help on using tickets.