On 02/09/18 16:51, Anthony Stone via shifter-users wrote: > Antoine, > > For the record: I find that after I stop an xpra session, I can't start > a new session on the same display with the same command that I have > always used previously, i.e. > xpra start ssh/whirligig/100 --start="gnome-terminal ..." > The log tells me that the lock file for the previous session needs to be > deleted, or that there is already an X session with that name, even if I > have exited from the terminal shell. > > However I can start a session with the same display using > xpra start ssh/whirligig/100 --use-display=yes --start="gnome-terminal ..." > In this case any terminal windows from the previous session that I > haven't closed explicitly reappear along with the new one. Previously > they were closed automatically when I invoked "xpra stop", which is what > I would prefer to happen. Which version are you running?
I believe you are hitting this bug: http://xpra.org/trac/ticket/1943 The workaround will be included in the next stable update. In the meantime, since the fix is a trivial one-liner, you could apply it by hand to your existing installation. Cheers, Antoine > > Anthony > > On 31/08/18 10:10, Anthony Stone via shifter-users wrote: >> Antoine, >> >> As recommended, I have set >> start-via-proxy=no >> in /etc/xpra/conf.d/60_server.conf >> (and restarted the server) >> and xpra now starts normally. >> >> Many thanks for the prompt and helpful advice. >> >> Anthony >> >> On 30/08/18 18:13, Antoine Martin wrote: >>> On 30/08/18 23:41, Anthony Stone wrote: >>>> Antoine, >>>> >>>> Thanks for the suggestions. This is what happens: >>> Please always keep the list CCed. >>> >>>> On 30/08/18 04:22, Antoine Martin via shifter-users wrote: >>>>> Directly on the server (ie: via ssh), try to start the session locally: >>>>> xpra start :100 --start="gnome-terminal --window-with-profile=Blue" >>>> >>>> 17:22:05 $ xpra start :100 --start="gnome-terminal >>>> --window-with-profile=Blue" >>>> 2018-08-30 17:22:46,020 server failure: disconnected before the session >>>> could be established >>>> 2018-08-30 17:22:46,020 server requested disconnect: server error >>>> (failed to start a new session) >>>> Warning: cannot use the system proxy for 'start' subcommand, >>>> unknown general failure >>>> more information may be available in your system log >>>> >>>> The system log contains the following. This seems to be an >>>> authentication failure, but I don't know how to fix it. >>>> >>>> Aug 30 17:22:32 whirligig systemd[1]: Started Session 2509 of user ajs1. >>>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>>> interactively either >>>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>>> interactively either >>> Here is what I think is happening: when we start a proper pam session >>> via root (this is what the "starting via proxy" does), we go through the >>> pam session configuration. >>> Your OS seems to include "pam_mount" in there, and that seems to want to >>> ask for a password to do its job. >>> I have no idea why that is, or why it isn't failing more gracefully. >>> >>>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,475 Error: >>>> pam_open_session failed: 6 >>>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,476 >>>> Permission denied >>>> Aug 30 17:22:32 whirligig xpra[1192]: Entering daemon mode; any further >>>> errors will be reported to: >>>> Aug 30 17:22:32 whirligig xpra[1192]: /run/user/1013/xpra/:100.log >>>> Aug 30 17:22:46 whirligig xpra[1192]: Error: failed to start server >>>> subprocess: >>>> Aug 30 17:22:46 whirligig xpra[1192]: failed to identify the new server >>>> display! >>> The easiest solution to this problem is to not use the proxy, set: >>> start-via-proxy=no >>> in your /etc/xpra/conf.d/60_server.conf >>> >>> On this subject, there seems to be so many ways that distributions >>> manage to configure (break) pam sessions, and logind's KillUserProcesses >>> still defaults to "no" after all these years, so future versions will >>> revert to not using the system wide proxy by default. >>> Those who want the features that require it will have to re-enable it. >>> >>> Cheers, >>> Antoine >>> >> _______________________________________________ >> shifter-users mailing list >> [email protected] >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > [email protected] > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
