[winswitch] Can't start xpra session

[Antoine Martin]

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