Xpra: Ticket #638: system tray menu needs a command-launcher

I normally start the xpra server with "--start-child=xterm", then connect to it, and in the xterm, I run the commands I need, such as "thunderbird".

However, if I inadvertently close the xterminal on the display side, then there is no way to run further commands. Both sides are still running Xpra, but it's now necessary to shut them both down and re-start from scratch. (It's no good to SSH in, set $DISPLAY, and then launch another xterm, because then if the connection temporarily dies, all the programs get terminated).

I think it would be really useful if the system-tray menu on the client included at least one of the following:

Thanks for your consideration, and for a really useful tool.



Tue, 19 Aug 2014 01:42:49 GMT - Antoine Martin: owner, status, component changed; milestone set

Yes, I agree that this would be a useful feature.

Until I can get around to implementing it, I can offer some workarounds which will ensure the process does not get terminated when the ssh connection dies:


Sat, 27 Dec 2014 12:57:18 GMT - Antoine Martin: owner, status changed

Implemented in:

How to use it:

Note: because this allows you to run arbitrary commands on the server, this feature is disabled by default. You must set start-new-commands=yes in your config file, or use the command line argument --start-new-commands=yes when starting the server.

Please test and give feedback.


Fri, 16 Jan 2015 11:37:48 GMT - Antoine Martin: owner changed

Not heard back, afarr? (mostly FYI)


Thu, 22 Jan 2015 02:13:18 GMT - alas:

Testing with OSX client 0.15.0 r8522 against fedora 20 server 0.15.0 (supposedly r8522, but displaying as runknown)... I'm getting the following error output when trying the xpra control channel:

[jimador@zapopan ~]$ xpra control :23 start-child xterm
server returned error code 1
this feature is currently disabled
[jimador@zapopan ~]$ xpra control :23 start-child=xterm
server returned error code 6
invalid command

(Though, 'start-child' is listed as one of the valid control channel commands, when the "=xterm" command produces an error.)

Trying to use --start-new-commands=yes client side, obviously, fails.

There doesn't seem to be any sign of a run-command dialog on OSX (and the About Xpra menu option is displaying empty rectangles in lieu of text, I'll make a separate ticket for that, with screen shots... as the GUI launcher also seems to be doing this... hopefully not just because of the runknown server build).

Trying with windows 8.1 client 0.15.0 r8500, the xpra control channel produces the same results, but the run-command - when failing- produces the interesting bit of output server-side:

started child 'start-child xterm' with pid 8412
/bin/sh: start-child: command not found
child 'start-child xterm' with pid 8412 has terminated

Thu, 22 Jan 2015 06:13:51 GMT - Antoine Martin: summary changed

this feature is currently disabled

Was a blooper - sorry about that, fixed in r8523.

Trying to use --start-new-commands=yes client side, obviously, fails.


Yes, that's as intended. The client does not get to choose if the feature is enabled or not on the server. It is listed in the "Server Controlled Features" in the xpra --help page.

Just to be clear, but I think you got that already: you must enable it in your server config by changing to: start-new-commands = yes in /etc/xpra/xpra.conf. The syntax to use is the one from comment:2, no double dashes are ever used with the control channel command arguments, those are reserved for the "xpra" command itself.

There doesn't seem to be any sign of a run-command dialog on OSX


Oops, I keep forgetting that OSX does everything different "because shiny". So r8525 adds this new "Run Command" menu entry to the "Actions" global OSX menu. (getting this simple thing to work on OSX took almost as long as the whole thing on client+server+every other platform. And infinitely more tedious. End of rant)


child 'start-child xterm' with pid 8412 has terminated


What did you type in the run command text input field? All you need in there is "xterm" (or whatever). Works fine here and I get on the server:

started child 'xterm' with pid 9161

And the new window appears on the client.


Thu, 22 Jan 2015 22:25:52 GMT - alas:

Testing again with fedora 20 server 0.15.0 r8527...

I did indeed input start-child xterm in the run command line. Inputting simply "xterm" works as expected.

The xpra control channel works as expected as well.

Testing with osx client 0.15.0 r8527, however, I'm still not finding the run-command option in the Actions global osx menu (though, with the Session Info gibberish output listed in #788, I am having a hard time confirming the osx client revision other than by the naming as part of the build).


Fri, 23 Jan 2015 01:09:42 GMT - Antoine Martin: attachment set

where the start-command menu entry is shown on osx


Fri, 23 Jan 2015 01:11:37 GMT - Antoine Martin:

I am having a hard time confirming the osx client revision other than by the naming as part of the build


xpra info | grep revision should show it as well.

I've uploaded a beta build so you can test it.

This is what it looks like: where the start-command menu entry is shown on osx


Thu, 12 Feb 2015 02:18:05 GMT - Antoine Martin:

You need to ensure --start-new-commands=yes is enabled on the server to see the start command option.. (it is off by default)


Thu, 12 Feb 2015 02:25:43 GMT - alas: attachment set

unhappy action menu


Thu, 12 Feb 2015 02:26:31 GMT - alas:

Testing again with fedora 20 server 0.15.0 r8601 (confirmed both in client output and xpra info) against osx client 0.15.0 r8640 (my build) ... I'm still not seeing any sign of a Run Command option in the Actions menu.

Instead, all I see is this:


unhappy action menu


Thu, 12 Feb 2015 02:29:20 GMT - Antoine Martin:

Please provide the full command line used at both ends.


Thu, 12 Feb 2015 21:21:42 GMT - alas: owner changed

Well that's embarrassing... sure enough, including the --start-new-commands=yes option made all the difference. See the Run Command option in osx, it works.

Looks good, assigning it back to you to close (after all that I don't trust myself to read correctly whether there are more bits to wrap up or not, though I think not).


Fri, 13 Feb 2015 01:03:45 GMT - Antoine Martin: status changed; resolution set


Sun, 28 Oct 2018 06:36:00 GMT - Antoine Martin:

Follow up: #1961.


Sat, 23 Jan 2021 05:01:37 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/638