Hi,
we've encountered an issue where (at least) X2Go client 4.0.0.3 on Windows can't resume certain sessions. If this has been discussed before please point me to the relevant threads/bugs; I didn't find anything.
The behavior is as follows: The affected version of the client is able to start new sessions, and also resume suspended sessions; however, resuming sessions after some delay (a few hours) causes the client to hang. Other versions of the client are then still able to resume this session, but even when resuming and suspending the session with a working client version, attempting to resume the session immediately afterwards in an affected client causes it to freeze.
I've tried the following versions so far:
3.99.2.1 on Linux: works 3.99.2.2 on Windows: works (n.b. filename is x2goclient-3.99.2.1-setup.exe) 4.0.0.3 on Windows: affected 4.0.1.1 on Linux: works
Server side versions are: x2goagent: 3.5.0.21 x2goserver: 4.0.1.6 x2goserver-xsession: 4.0.1.6
Can anybody confirm that this is something which has been fixed in client 4.0.1? If so, when is there going to be a 4.0.1 client for Windows? (In the meantime, we're downgrading our Windows users to 3.99.)
- Sebastian
On Fri, Oct 18, 2013 at 7:18 AM, Sebastian Flothow <sebastian.flothow@gip.com> wrote:
we've encountered an issue where (at least) X2Go client 4.0.0.3 on Windows can't resume certain sessions. If this has been discussed before please point me to the relevant threads/bugs; I didn't find anything.
The behavior is as follows: The affected version of the client is able to start new sessions, and also resume suspended sessions; however, resuming sessions after some delay (a few hours) causes the client to hang. Other versions of the client are then still able to resume this session, but even when resuming and suspending the session with a working client version, attempting to resume the session immediately afterwards in an affected client causes it to freeze.
I've tried the following versions so far:
3.99.2.1 on Linux: works 3.99.2.2 on Windows: works (n.b. filename is x2goclient-3.99.2.1-setup.exe) 4.0.0.3 on Windows: affected 4.0.1.1 on Linux: works
Server side versions are: x2goagent: 3.5.0.21 x2goserver: 4.0.1.6 x2goserver-xsession: 4.0.1.6
Can anybody confirm that this is something which has been fixed in client 4.0.1? If so, when is there going to be a 4.0.1 client for Windows? (In the meantime, we're downgrading our Windows users to 3.99.)
I have had the same problem on Windows client versions 4.0.1.0 and 4.0.0.3 for quite a while now. There does NOT appear to be a Windows binary version 4.0.1.1 available for download.
One thing that usually works is to restart the server process (I am running the systemd x2goserver 4.0.1.6-1). Then I will be able to resume a session that previously hung the windows client.
Another odd thing that I have noticed with the Windows client is that sometimes when I click on a session, it brings up the dialog box showing a suspended session, but the resume button is greyed out and does not respond. Still, I can double-click on the session line in the list and it tries to resume, but it will often hang if it has been suspended for several hours (same behavior you noted). Then I restart x2goserver.service, and I can resume the session.
Am 19.10.2013 05:45, schrieb John Williams:
One thing that usually works is to restart the server process
I just had a look at /etc/init.d/x2goserver on my box, the only thing being started there is x2gocleansessions. Is this what you're referring to?
Is x2gocleansessions supposed to continue running in the background? There are no x2gocleansessions processes running on my machine right now.
- Sebastian
On Mon, Oct 21, 2013 at 12:11 AM, Sebastian Flothow <sebastian.flothow@gip.com> wrote:
Am 19.10.2013 05:45, schrieb John Williams:
One thing that usually works is to restart the server process
I just had a look at /etc/init.d/x2goserver on my box, the only thing being started there is x2gocleansessions. Is this what you're referring to?
Is x2gocleansessions supposed to continue running in the background? There are no x2gocleansessions processes running on my machine right now.
I am running the x2goserver package from Archlinux, which uses systemd. After I found out that restarting x2goserver.service via systemd would usually allow me to resume a session from a Windows client (without hanging), I set up a cron job on my linux box that restarts it every hour.
Here is the unit file /etc/systemd/system/multi-user.target.wants/x2goserver.service
[Unit] Description=x2go - remote desktop server After=syslog.target network.target
[Service] ExecStart=/usr/bin/x2gocleansessions PIDFile=/run/x2goserver.pid
[Install] WantedBy=multi-user.target
Hi John,
On Mo 21 Okt 2013 10:07:37 CEST, John Williams wrote:
On Mon, Oct 21, 2013 at 12:11 AM, Sebastian Flothow <sebastian.flothow@gip.com> wrote:
Am 19.10.2013 05:45, schrieb John Williams:
One thing that usually works is to restart the server process
I just had a look at /etc/init.d/x2goserver on my box, the only thing being started there is x2gocleansessions. Is this what you're referring to?
Is x2gocleansessions supposed to continue running in the background? There are no x2gocleansessions processes running on my machine right now.
I am running the x2goserver package from Archlinux, which uses systemd. After I found out that restarting x2goserver.service via systemd would usually allow me to resume a session from a Windows client (without hanging), I set up a cron job on my linux box that restarts it every hour.
The x2gocleansessions script forks itself and becomes a daemon
process. It should run on your system permanently. It contains a loop
that executes its code every 2 seconds (older versions of X2Go Server:
every 5 seconds).
Here is the unit file /etc/systemd/system/multi-user.target.wants/x2goserver.service
[Unit] Description=x2go - remote desktop server After=syslog.target network.target
[Service] ExecStart=/usr/bin/x2gocleansessions PIDFile=/run/x2goserver.pid
x2gocleansessions belongs to /usr/sbin, not /usr/bin. Please contact
the archlinux maintainer of X2Go Server and tell him that.
Also, we will be happy to include a service file, once it's proven to work...
[Install] WantedBy=multi-user.target
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
I'm not sure what your point is. None of that addresses the root issue that the thread starter mentioned, or that I confirmed.
And as I said, restarting x2goserver, which restarts x2gocleansessions, usually allows the Windows client to resume the session. I don't know why, but it is a fact that it usually does the trick for me (although not always, I'd say its around 90%)
I am not going to contact the Archlinux package maintainer and tell him where to put the binaries, since as far as I am concerned, he can put them wherever he likes. You are welcome to contact him if it bothers you.
On Mo 21 Okt 2013 14:14:00 CEST, John Williams wrote:
I'm not sure what your point is. None of that addresses the root issue that the thread starter mentioned, or that I confirmed.
And as I said, restarting x2goserver, which restarts x2gocleansessions, usually allows the Windows client to resume the session. I don't know why, but it is a fact that it usually does the trick for me (although not always, I'd say its around 90%)
What I responded to is an issue with x2gocleansessions. If it gets
started on ArchLinux systems and then disappears, it is quite obvious
that it crashes somewhere in its ,,while (sleep 2)''-loop.
So, you should find out why it crashes (it has been written in Perl).
Once that bug is found (IMHO it is distro specific), then the
originally addressed issue in this thread may be solved, as well.
Permanently restarting the x2gocleansessions script is a workaround,
not a solution.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Mon, Oct 21, 2013 at 5:48 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
What I responded to is an issue with x2gocleansessions. If it gets started on ArchLinux systems and then disappears, it is quite obvious that it crashes somewhere in its ,,while (sleep 2)''-loop.
I never said x2gocleansessions disappears. It is still there. Until the restart, which kills it and starts it again.
On Mo 21 Okt 2013 14:55:11 CEST, John Williams wrote:
On Mon, Oct 21, 2013 at 5:48 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
What I responded to is an issue with x2gocleansessions. If it gets started on ArchLinux systems and then disappears, it is quite obvious that it crashes somewhere in its ,,while (sleep 2)''-loop.
I never said x2gocleansessions disappears. It is still there. Until the restart, which kills it and starts it again.
Ah, ok... A misunderstanding on my side...
So, as the issue does not occur here (Debian based systems), the
question is, why is the while loop hanging when x2gocleansession is
handled via systemd...
Could you add some log messages, so that we can see if something
happens at all in the while loop?
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Mon, Oct 21, 2013 at 6:01 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
On Mo 21 Okt 2013 14:55:11 CEST, John Williams wrote:
On Mon, Oct 21, 2013 at 5:48 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
What I responded to is an issue with x2gocleansessions. If it gets started on ArchLinux systems and then disappears, it is quite obvious that it crashes somewhere in its ,,while (sleep 2)''-loop.
I never said x2gocleansessions disappears. It is still there. Until the restart, which kills it and starts it again.
Ah, ok... A misunderstanding on my side...
So, as the issue does not occur here (Debian based systems), the question is, why is the while loop hanging when x2gocleansession is handled via systemd...
No! This is getting ridiculous. systemd is not the problem
The problem was already described in the first and second emails in this thread. It is that with certain versions of the Windows client, the client hangs when we try to resume the session. I thought it was clearly explained, so I can only guess that you did not read those emails.
Also note that Sebastian found that the hang did NOT occur with another version of the client. That is a key piece of evidence.
I confirmed that two versions of the Windows client also hangs for me when I try to resume the session.
Try to forget about the workaround that I mentioned of restarting x2goserver. That is not the central issue here.
Am 21.10.2013 14:55, schrieb John Williams:
I never said x2gocleansessions disappears. It is still there. Until the restart, which kills it and starts it again.
There seems to be some confusion here - it was my machine where x2gocleansessions disappeared. I'm running Debian Wheezy, with up-to-date packages from http://packages.x2go.org/debian.
I only noticed this today, so I don't know when x2gocleansessions exited, or if this has happened before. I'll keep an eye out for it.
Still, I'm not sure if this is related to the original problem.
- Sebastian
Hi John,
On Mo 21 Okt 2013 10:07:37 CEST, John Williams wrote:
On Mon, Oct 21, 2013 at 12:11 AM, Sebastian Flothow <sebastian.flothow@gip.com> wrote:
Am 19.10.2013 05:45, schrieb John Williams:
One thing that usually works is to restart the server process
I just had a look at /etc/init.d/x2goserver on my box, the only thing being started there is x2gocleansessions. Is this what you're referring to?
Is x2gocleansessions supposed to continue running in the background? There are no x2gocleansessions processes running on my machine right now.
I am running the x2goserver package from Archlinux, which uses systemd. After I found out that restarting x2goserver.service via systemd would usually allow me to resume a session from a Windows client (without hanging), I set up a cron job on my linux box that restarts it every hour.
The x2gocleansessions script forks itself and becomes a daemon
process. It should run on your system permanently. It contains a loop
that executes its code every 2 seconds (older versions of X2Go Server:
every 5 seconds).
Here is the unit file /etc/systemd/system/multi-user.target.wants/x2goserver.service
[Unit] Description=x2go - remote desktop server After=syslog.target network.target
[Service] ExecStart=/usr/bin/x2gocleansessions PIDFile=/run/x2goserver.pid
x2gocleansessions belongs to /usr/sbin, not /usr/bin. Please contact
the archlinux maintainer of X2Go Server and tell him that.
Also, we will be happy to include a service file, once it's proven to work...
[Install] WantedBy=multi-user.target
Greets, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Mike Gabriel píše v Po 21. 10. 2013 v 10:52 +0000:
x2gocleansessions belongs to /usr/sbin, not /usr/bin. Please contact
the archlinux maintainer of X2Go Server and tell him that.
Arch Linux merged /bin, /sbin, /usr/sbin to /usr/bin recently. For compatibility reasons, there are symlinks from the former ones to /usr/bin.
More info at https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.ht...
For Arch Linux package maintainers, it does not really matter, which path is used. For compatibility with other systems, /usr/sbin might be a better choice.
cheers, Milan
-- http://milan-knizek.net/ About linux and photography (Czech only) O linuxu a fotografování
On Fr 01 Nov 2013 15:51:18 CET, Milan Knížek wrote:
Mike Gabriel píše v Po 21. 10. 2013 v 10:52 +0000:
x2gocleansessions belongs to /usr/sbin, not /usr/bin. Please contact the archlinux maintainer of X2Go Server and tell him that.
Arch Linux merged /bin, /sbin, /usr/sbin to /usr/bin recently. For compatibility reasons, there are symlinks from the former ones to /usr/bin.
Why the hack have they done this???
:-/ Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Multiple Linux Distros are doing this for very good reasons:
https://lists.fedoraproject.org/pipermail/devel/2011-October/158845.html
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
On Fri, Nov 1, 2013 at 11:01 AM, Mike Gabriel < mike.gabriel@das-netzwerkteam.de> wrote:
On Fr 01 Nov 2013 15:51:18 CET, Milan Knížek wrote:
Mike Gabriel píše v Po 21. 10. 2013 v 10:52 +0000:
x2gocleansessions belongs to /usr/sbin, not /usr/bin. Please contact
the archlinux maintainer of X2Go Server and tell him that.
Arch Linux merged /bin, /sbin, /usr/sbin to /usr/bin recently. For compatibility reasons, there are symlinks from the former ones to /usr/bin.
Why the hack have they done this???
:-/
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das- netzwerkteam.de.xfb
X2Go-User mailing list X2Go-User@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-user
On Fri, Oct 18, 2013 at 7:18 AM, Sebastian Flothow <sebastian.flothow@gip.com> wrote:
The behavior is as follows: The affected version of the client is able to start new sessions, and also resume suspended sessions; however, resuming sessions after some delay (a few hours) causes the client to hang. Other versions of the client are then still able to resume this session, but even when resuming and suspending the session with a working client version, attempting to resume the session immediately afterwards in an affected client causes it to freeze.
I've tried the following versions so far:
3.99.2.1 on Linux: works 3.99.2.2 on Windows: works (n.b. filename is x2goclient-3.99.2.1-setup.exe) 4.0.0.3 on Windows: affected 4.0.1.1 on Linux: works
Server side versions are: x2goagent: 3.5.0.21 x2goserver: 4.0.1.6 x2goserver-xsession: 4.0.1.6
Can anybody confirm that this is something which has been fixed in client 4.0.1? If so, when is there going to be a 4.0.1 client for Windows? (In the meantime, we're downgrading our Windows users to 3.99.)
I spent some time testing several versions of the Windows client, and I can confirm the behavior you mention, and add a few more versions:
Note that the problem is somewhat intermittent. Waiting a few hours to resume a session makes it more likely to hang during connection, but it does not always hang. So I spent some time with each version, repeatedly trying to resume sesssions, sometimes immediately, sometimes after the session has been suspended for hours. When I say it "works" I mean that I never got it to hang. When I say that it hangs, I mean that it hung at least once (usually more than once, though).
Linux server: x2go-agent 3.5.0.21 x2goserver 4.0.1.6
Windows client: 3.99.2.1 filename (3.99.2.2 about box): works 3.99.3.1-pre1_interims (old pulseaudio): hangs 4.0.0.3: hangs 4.0.0.3_interims (old pulseaudio): hangs 4.0.1.0-pre02 : hangs
So it appears that this issue was introduced between 3.99.2.1(3.99.2.2) and 3.99.3.1-pre1. Also, it does NOT appear to be a consequence of the new pulseaudio version, since the old interims version has the same issue.
Perhaps the program maintainer can check the changelog between then and deduce what is causing the intermittent hang during connection issue.
-
John Williams -
Michael DePaulo -
Mike Gabriel -
Milan Knížek -
Sebastian Flothow