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.
How would we identify the processes to display here?
start
/ start-child
and friends?
We could offer different actions for each process:
etc..
Some more work in this area is already planned: #1671
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.
what the new server commands dialog looks like
Implemented in:
The end result looks like this:
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.
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-terminal
s, 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).
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.
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...
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
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
@maxmylyn: FYI, feel free to close.
Noted and closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1702