X2Go Bug report logs - #1117
x2goclient "stuck session" for select users that cannot be resumed or terminated

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Jordan Poppenk <jpoppenk@queensu.ca>

To: "submit@bugs.x2go.org" <submit@bugs.x2go.org>

Subject: x2goclient "stuck session" for select users that cannot be resumed or terminated

Date: Mon, 28 Nov 2016 22:31:21 +0000

Package: x2goclient (mac)
Version: 4.0.5.2

Above is my best guess as to the affected package, although I am not certain it is on the client end. Also, my issue is similar to the one reported here:
http://lists.x2go.org/pipermail/x2go-dev/2015-October/010734.html
...but that thread concludes without a solution that works for me.

x2go had been working for a dozen users of my server. One day, two of the users reported that they were no longer able to log in -- they were kicked back to the login screen after entering their ssh private key encryption password. After entering this, the users get the result: 
- Session: Session session started at: (date)
- Warning: Protocol mismatch or no X authentication data.
- Session: Terminating session at (date)
- Info: Your session was closed before reaching a usable state.
- Info: This can be due to the local X server refusing access to the client.
- Info: Please check authorization provided by the remote X application.
- Session: Session terminated at (date)
Sometimes, they are presented with a list of sessions that shows their "running" session. It allows them to terminate the session, then brings them back to the screen where they would terminate the session.

It is worth noting that their configuration was previously working. Also, I am sometimes able to fix issues like this by deleting the user's .Xauthority files, their .x2go folder, and their cache/lxsession folder; and rebooting. In this case, none of these things influenced the outcome of their login attempts. But, many other users are still able to access x2go normally on the same machine.

Both affected users are using the mac x2goclient (4.0.5.2) with xquartz 2.7.9 on OSX 10.11.6. On my server (running Ubuntu 16.04), x2goversion reports the following:
x2goagent: 3.5.0.32
x2godesktopsharing: 3.1.1.3
x2golxdebindings: 1.0.2.4
x2goserver: 4.0.1.19
x2goserver-extensions: 4.0.1.19
x2goserver-xsession: 4.0.1.19
It is worth noting that I sometimes experienced similar issues while still using Ubuntu 14.04.

A third user recently reported that after a crash that occurred after opening too many windows in her session, she started getting the same errors, which I have also been unable to resolve. Are you able to suggest any remedy? Where might the information about the "stuck session" live -- perhaps I could try deleting some session file that is stored on the user's machine?

Thank you in advance for any help you can offer, as well as your extremely helpful ongoing development of this portable desktop solution.

Cheers,
Jordan


Jordan Poppenk, Ph.D.
Canada Research Chair in Cognitive Neuroimaging
Department of Psychology and Centre for Neuroscience Studies
Queen's University
http://popmem.com
613-533-6009

Message #10 received at 1117@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: 1117@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1117: x2goclient "stuck session" for select users that cannot be resumed or terminated

Date: Tue, 29 Nov 2016 12:57:01 +0100

[Message part 1 (text/plain, inline)]

Am 28.11.2016 um 23:31 schrieb Jordan Poppenk:
> Package: x2goclient (mac)
> Version: 4.0.5.2
>
> Above is my best guess as to the affected package, although I am not certain it is on the client end. Also, my issue is similar to the one reported here:
> http://lists.x2go.org/pipermail/x2go-dev/2015-October/010734.html
> ...but that thread concludes without a solution that works for me.
>
> x2go had been working for a dozen users of my server. One day, two of the users reported that they were no longer able to log in -- they were kicked back to the login screen after entering their ssh private key encryption password. After entering this, the users get the result: 
> - Session: Session session started at: (date)
> - Warning: Protocol mismatch or no X authentication data.
> - Session: Terminating session at (date)
> - Info: Your session was closed before reaching a usable state.
> - Info: This can be due to the local X server refusing access to the client.
> - Info: Please check authorization provided by the remote X application.
> - Session: Session terminated at (date)
> Sometimes, they are presented with a list of sessions that shows their "running" session. It allows them to terminate the session, then brings them back to the screen where they would terminate the session.
>
> It is worth noting that their configuration was previously working. Also, I am sometimes able to fix issues like this by deleting the user's .Xauthority files, their .x2go folder, and their cache/lxsession folder; and rebooting. In this case, none of these things influenced the outcome of their login attempts. But, many other users are still able to access x2go normally on the same machine.

What happens when you, as root, execute:

x2golistsessions_root

Do you see the "hung" sessions of your users?

What happens when you terminate them using

(again, as root, and preferably not in an X2Go session yourself)

x2goterminate-session <sessionid>

(<sessionid> is what you see in the second output column of
x2golistsessions_root)

Does it work for them afterwards?

What happens when you set up a separate test server with X2Go on it, can
they connect to that one, or are they having issues with it as well?


> Jordan Poppenk, Ph.D.
> Canada Research Chair in Cognitive Neuroimaging
> Department of Psychology and Centre for Neuroscience Studies
> Queen's University
> http://popmem.com
> 613-533-6009

There are two things I would like to mention, due to your e-mail signature:

First, a warning:
X2Go does have options for image compression, like using JPG and/or PNG.
Not all image compression algorithms are lossless, and thus there may be
artifacts in the images (i.e. the image displayed through X2Go may look
slightly different than what it would look like on a regular X-Server
screen), depending on which algorithm and which compression level you
choose. Is that something you're aware of?

If you're using fMRI/X-Ray/Mammography/... images displayed through X2Go
for clinical purposes (deciding whether a certain patient requires a
surgery etc.), you should absolutely make sure that you're using a
lossless compression or no compression at all, or else you might be
seeing things that aren't actually there, or missing things that are there.

Second, a shameless plug advertising our commercial services:
<shameless plug>
X2Go also has a commercial side, where various companies - including my
own - offer support contracts with guaranteed response times as well as
consultancy and paid-for development work if someone wants to see a bug
fixed or a new feature added in a certain time frame. What makes my
company special is, IMHO:

1) I'm the current X2Go Project/Community Coordinator, so the
development lead and the developers tend to listen to me.
2) As far as I know, we are the only company providing X2Go support that
isn't a one-man-show.
3) We sub-contract other developers from the X2Go community on demand,
so you only have one person you need to talk to - me - and you will only
receive one invoice, even if the task involved several freelance or
part-time X2Go developers.

Our hourly rate for consultancy work and fixing issues outside of a
support contract is 110 EUR. With a support contract, you get guaranteed
response times (starting at 400 EUR/month for 24h response time during
business hours in the CET/CEST time zone from Monday to Friday, German
holidays excluded) and lower hourly rates if you buy a certain amount of
hours in advance.
</shameless plug>

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.