[winswitch] Can't start xpra session

[Anthony Stone]

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
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>