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