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.
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:
nohup
disown
the process after starting it in the background
screen
(or tmux
)
Implemented in:
How to use it:
xpra control :10 start-child xterm
Alt + Shift + F2
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.
Not heard back, afarr? (mostly FYI)
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
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.
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).
where the start-command menu entry is shown on osx
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.
You need to ensure --start-new-commands=yes
is enabled on the server to see the start command option.. (it is off by default)
unhappy action menu
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:
Please provide the full command line used at both ends.
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).
Follow up: #1961.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/638