Sometimes x2go works fine. Other times I can't get the session back and logs look like this. server version 4.0.1.20. Same results occur when connecting from my Windows or Linux client.
$ uname -a Linux hercules 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
==> messages <== Nov 18 02:00:32 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully
==> secure <== Nov 18 02:00:35 hercules sshd[33053]: Accepted password for andrew from 104.133.2.65 port 42971 ssh2
==> messages <== Nov 18 02:00:35 hercules systemd-logind: New session 13589 of user andrew. Nov 18 02:00:35 hercules systemd: Started Session 13589 of user andrew. Nov 18 02:00:35 hercules systemd: Starting Session 13589 of user andrew.
==> secure <== Nov 18 02:00:35 hercules sshd[33053]: pam_unix(sshd:session): session opened for user andrew by (uid=0)
==> messages <== Nov 18 02:00:41 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:00:44 hercules su: (to andrew) root on none Nov 18 02:00:44 hercules systemd: Started Session c387 of user andrew. Nov 18 02:00:44 hercules systemd: Starting Session c387 of user andrew.
==> secure <== Nov 18 02:00:44 hercules su: pam_unix(su:session): session opened for user andrew by (uid=0) Nov 18 02:00:44 hercules su: pam_unix(su:session): session closed for user andrew
==> messages <== Nov 18 02:00:44 hercules su: (to andrew) root on none Nov 18 02:00:44 hercules systemd: Started Session c388 of user andrew. Nov 18 02:00:44 hercules systemd: Starting Session c388 of user andrew.
==> secure <== Nov 18 02:00:44 hercules su: pam_unix(su:session): session opened for user andrew by (uid=0)
==> messages <== Nov 18 02:00:45 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:00:46 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully
==> secure <== Nov 18 02:00:47 hercules su: pam_unix(su:session): session closed for user andrew
==> messages <== Nov 18 02:00:50 hercules /usr/sbin/x2gocleansessions[3217]: andrew-51-1508260775_stDMATE_dp32: session status S desynchronized with current status (R) and session suspend already tried unsuccessfully Nov 18 02:00:50 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:00:54 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:01:00 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:01:01 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:01:01 hercules systemd: Created slice user-0.slice. Nov 18 02:01:01 hercules systemd: Starting user-0.slice. Nov 18 02:01:01 hercules systemd: Started Session 13590 of user root. Nov 18 02:01:01 hercules systemd: Starting Session 13590 of user root. Nov 18 02:01:01 hercules systemd: Removed slice user-0.slice. Nov 18 02:01:01 hercules systemd: Stopping user-0.slice. Nov 18 02:01:03 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully Nov 18 02:01:07 hercules /usr/bin/x2gosuspend-session: session with ID andrew-51-1508260775_stDMATE_dp32 has been suspended successfully
- On 11/18/2017 09:32 AM, Andrew Munn wrote:
Sometimes x2go works fine. Other times I can't get the session back and logs look like this. server version 4.0.1.20. Same results occur when connecting from my Windows or Linux client.
Might that be the same problem as described by the other user - i.e., something deleting files in /tmp/, which stores the session data?
Does that problem only happen after the session has been created for a while?
Mihai
Yes deleting /tmp/.x2go-$USER did fix it. It happens rarely. I'm not sure how long the session runs before this occurs. A fix for this issue would be great. Thanks for the suggestion!
On Sat, 18 Nov 2017, Mihai Moldovan wrote:
- On 11/18/2017 09:32 AM, Andrew Munn wrote:
Sometimes x2go works fine. Other times I can't get the session back and logs look like this. server version 4.0.1.20. Same results occur when connecting from my Windows or Linux client.
Might that be the same problem as described by the other user - i.e., something deleting files in /tmp/, which stores the session data?
Does that problem only happen after the session has been created for a while?
Mihai
- On 11/19/2017 11:21 AM, Andrew Munn wrote:
Yes deleting /tmp/.x2go-$USER did fix it. It happens rarely. I'm not sure how long the session runs before this occurs. A fix for this issue would be great. Thanks for the suggestion!
Uh, no, my suggestion was *not* to delete this data, it was to make sure that *nothing* deletes this data in the first place.
Congrats, in the best case x2gocleansessions killed the session after the metadata vanished, in the worst case you have a stale x2goagent/nxagent process still running...
Mihai
On Sun, 19 Nov 2017, Mihai Moldovan wrote:
- On 11/19/2017 11:21 AM, Andrew Munn wrote:
Yes deleting /tmp/.x2go-$USER did fix it. It happens rarely. I'm not sure how long the session runs before this occurs. A fix for this issue would be great. Thanks for the suggestion!
Uh, no, my suggestion was *not* to delete this data, it was to make sure that *nothing* deletes this data in the first place.
Congrats, in the best case x2gocleansessions killed the session after the metadata vanished, in the worst case you have a stale x2goagent/nxagent process still running...
What's the correct fix? I'd rather not lose my sessions by deleting these files if possible. -Andrew
I'm seeing this situation again. I can see the session in the client as usual by when I click on it nothing happens. I think someone in another thread mentioned running out of available ports as a possible cause. Is that right? What's the solution here? I want to reconnect to the session without killing my running applications.
Thanks
On Sun, 19 Nov 2017, Mihai Moldovan wrote:
- On 11/19/2017 11:21 AM, Andrew Munn wrote:
Yes deleting /tmp/.x2go-$USER did fix it. It happens rarely. I'm not sure how long the session runs before this occurs. A fix for this issue would be great. Thanks for the suggestion!
Uh, no, my suggestion was *not* to delete this data, it was to make sure that *nothing* deletes this data in the first place.
Congrats, in the best case x2gocleansessions killed the session after the metadata vanished, in the worst case you have a stale x2goagent/nxagent process still running...
Mihai
- On 01/10/2018 04:13 PM, Andrew Munn wrote:
I'm seeing this situation again. I can see the session in the client as usual by when I click on it nothing happens. I think someone in another thread mentioned running out of available ports as a possible cause. Is that right? What's the solution here? I want to reconnect to the session without killing my running applications.
Running out of usable ports is possible, but shouldn't happen unless the session database is not cleaned up properly or there are huge amounts of sessions running.
Does x2golistsessions_root output something reasonable?
I've recently worked on port detection. This probably will not really help if there are no free ports left, but at least pass back a more or less useful message to x2go client in such as case.
It's not part of any released code yet, so nothing you would care in the first place anyway.
Are you positive that session data is still available either in ~user/.x2go or /tmp/.x2go-$user/?
Note that some systems delete files out of /tmp regularly!
Mihai
I get reasonable output from x2golistsessions_root. I also see a matching directory in /tmp/.x2go-$user/ containing 3 files:
[root@hercules C-andrew-51-1513021653_stDMATE_dp24]# ls total 12 -rw-rw-r-- 1 andrew andrew 1 Jan 10 08:56 options -rw-rw-r-- 1 andrew andrew 12 Jan 10 08:56 sshd.pid -rw-rw-r-- 1 andrew andrew 8 Jan 10 08:56 state [root@hercules C-andrew-51-1513021653_stDMATE_dp24]#
I log in successfully then double-click the session I want but nothing happens afterwards.
/var/log/secure looks like this: Jan 15 18:58:31 hercules sshd[56388]: Accepted password for andrew from x.x.x.x port 39052 ssh2 Jan 15 18:58:31 hercules sshd[56388]: pam_unix(sshd:session): session opened for user andrew by (uid=0) Jan 15 18:58:40 hercules su: pam_unix(su:session): session opened for user andrew by (uid=0) Jan 15 18:58:41 hercules su: pam_unix(su:session): session closed for user andrew Jan 15 18:58:41 hercules su: pam_unix(su:session): session opened for user andrew by (uid=0) Jan 15 18:58:43 hercules su: pam_unix(su:session): session closed for user andrew
No errors are being appended to ~/.xsession-x2go-*
Is there some other place I should be looking for errors?
I can delete the session files and then create a new one. Or I can click "new" instead of double-clicking on the session. Clicking "new" will create an additional session and when I disconnect/reconnect I now see 2 sessions. One is status "running" and one is "suspended". The running one is the old one which I can still not connect to.
Thanks
-Andrew
On Sat, 13 Jan 2018, Mihai Moldovan wrote:
- On 01/10/2018 04:13 PM, Andrew Munn wrote:
I'm seeing this situation again. I can see the session in the client as usual by when I click on it nothing happens. I think someone in another thread mentioned running out of available ports as a possible cause. Is that right? What's the solution here? I want to reconnect to the session without killing my running applications.
Running out of usable ports is possible, but shouldn't happen unless the session database is not cleaned up properly or there are huge amounts of sessions running.
Does x2golistsessions_root output something reasonable?
I've recently worked on port detection. This probably will not really help if there are no free ports left, but at least pass back a more or less useful message to x2go client in such as case.
It's not part of any released code yet, so nothing you would care in the first place anyway.
Are you positive that session data is still available either in ~user/.x2go or /tmp/.x2go-$user/?
Note that some systems delete files out of /tmp regularly!
Mihai
Am 16.01.2018 um 02:32 schrieb Andrew Munn:
I can delete the session files and then create a new one. Or I can click "new" instead of double-clicking on the session. Clicking "new" will create an additional session and when I disconnect/reconnect I now see 2 sessions. One is status "running" and one is "suspended". The running one is the old one which I can still not connect to.
Just stating the obvious, I guess, but to be able to resume a running session, you have to suspend it first - either from within, or by clicking the "Suspend" button in that menu where the session is presented to you as running (The top one of the three buttons on the right, saying Suspend, Terminate, New).
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
On Tue, 16 Jan 2018, Stefan Baur wrote:
Am 16.01.2018 um 02:32 schrieb Andrew Munn:
I can delete the session files and then create a new one. Or I can click "new" instead of double-clicking on the session. Clicking "new" will create an additional session and when I disconnect/reconnect I now see 2 sessions. One is status "running" and one is "suspended". The running one is the old one which I can still not connect to.
Just stating the obvious, I guess, but to be able to resume a running session, you have to suspend it first - either from within, or by clicking the "Suspend" button in that menu where the session is presented to you as running (The top one of the three buttons on the right, saying Suspend, Terminate, New).
Double clicking on the line is the same a clicking "resume", correct? If a session is in the suspended state I can resume it. I currently have a session in the running state. I can click suspend and it changes to "suspended". At that point I can click Resume because the button becomes enabled. Nothing happens when I click Resume. This is the same behavior as double-clicking on the session. When things are working correctly double-clicking the session opens it howevever when in this non-working state clicking does nothing.
I don't know if the session data is screwed up on the server or what.
Maybe I need to enable verbose logging and wait for this situation to
recur? This happens about once a month or less.
- On 01/16/2018 02:32 AM, Andrew Munn wrote:
I get reasonable output from x2golistsessions_root. I also see a matching directory in /tmp/.x2go-$user/ containing 3 files:
[root@hercules C-andrew-51-1513021653_stDMATE_dp24]# ls total 12 -rw-rw-r-- 1 andrew andrew 1 Jan 10 08:56 options -rw-rw-r-- 1 andrew andrew 12 Jan 10 08:56 sshd.pid -rw-rw-r-- 1 andrew andrew 8 Jan 10 08:56 state [root@hercules C-andrew-51-1513021653_stDMATE_dp24]#
Hm, that doesn't look right. A suspended session's directory should contain many more files, like a spool symlink, a cache directory, a mimebox symlink, an options file, a cmdoutput file, a state file and maybe others.
I really do believe that something is deleting files in /tmp/ without you knowing it!
Did you really check for a cron job or the like that might clean up /tmp/? It looks like CentOS 7 has this configurable in /usr/lib/tmpfiles.d/tmp.conf and uses systemd for that purpose.
Mihai
Thanks! I've added the following line to /usr/lib/tmpfiles.d/tmp.conf
x /tmp/.x2go-*
Hopefully that fixes it. Do you think there should be some automated process to append that line during installation on a CentOS/RHEL system?
Andrew
On Mon, 22 Jan 2018, Mihai Moldovan wrote:
- On 01/16/2018 02:32 AM, Andrew Munn wrote:
I get reasonable output from x2golistsessions_root. I also see a matching directory in /tmp/.x2go-$user/ containing 3 files:
[root@hercules C-andrew-51-1513021653_stDMATE_dp24]# ls total 12 -rw-rw-r-- 1 andrew andrew 1 Jan 10 08:56 options -rw-rw-r-- 1 andrew andrew 12 Jan 10 08:56 sshd.pid -rw-rw-r-- 1 andrew andrew 8 Jan 10 08:56 state [root@hercules C-andrew-51-1513021653_stDMATE_dp24]#
Hm, that doesn't look right. A suspended session's directory should contain many more files, like a spool symlink, a cache directory, a mimebox symlink, an options file, a cmdoutput file, a state file and maybe others.
I really do believe that something is deleting files in /tmp/ without you knowing it!
Did you really check for a cron job or the like that might clean up /tmp/? It looks like CentOS 7 has this configurable in /usr/lib/tmpfiles.d/tmp.conf and uses systemd for that purpose.
Mihai
- On 01/22/2018 10:28 PM, Andrew Munn wrote:
Thanks! I've added the following line to /usr/lib/tmpfiles.d/tmp.conf
x /tmp/.x2go-*
Hopefully that fixes it.
Then again, according to https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-... and the general file system hierarchy, /usr/lib is not a good place to make changes.
Thankfully you should be able to move this into /etc/tmpfiles.d/x2go.conf and have that setting persist between system updates.
Do you think there should be some automated process to append that line during installation on a CentOS/RHEL system?
Yes, I should add this file to the general packaging! It's impressive how many workarounds are necessary for systemd in order for it not to break everything...
Mihai
Yes, you gotta love systemd. There is an upside though, it's abouttwo seconds between the time my BIOS fires off the boot block and I've got a desktop login screen, under the old start up system it was more like 30 seconds.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Wed, 24 Jan 2018, Mihai Moldovan wrote:
Date: Wed, 24 Jan 2018 07:36:24 +0100 From: Mihai Moldovan <ionic@ionic.de> To: Andrew Munn <andrew@nmedia.net> Cc: x2go-user@lists.x2go.org Subject: Re: [X2Go-User] can't connect to session
- On 01/22/2018 10:28 PM, Andrew Munn wrote:
Thanks! I've added the following line to /usr/lib/tmpfiles.d/tmp.conf
x /tmp/.x2go-*
Hopefully that fixes it.
Then again, according to https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-... and the general file system hierarchy, /usr/lib is not a good place to make changes.
Thankfully you should be able to move this into /etc/tmpfiles.d/x2go.conf and have that setting persist between system updates.
Do you think there should be some automated process to append that line during installation on a CentOS/RHEL system?
Yes, I should add this file to the general packaging! It's impressive how many workarounds are necessary for systemd in order for it not to break everything...
Mihai
*ahem*
I am one of the list-admins, and as much as I loathe SystemD, I would like to remind *everyone* reading this that having a love/hate SystemD thread on here is bound to end in a flamewar, so let's stop here before this ends in chaos.
Thank you.
Kind Regards, Stefan Baur
PS: Robert, your tone was civil, so don't take this as personal criticism or public shaming, it's a general reminder to *everyone*.
Am 24.01.2018 um 08:36 schrieb Robert Dinse:
Yes, you gotta love systemd. There is an upside though, it's about two seconds between the time my BIOS fires off the boot block and I've got a desktop login screen, under the old start up system it was more like 30 seconds.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Wed, 24 Jan 2018, Mihai Moldovan wrote:
Date: Wed, 24 Jan 2018 07:36:24 +0100 From: Mihai Moldovan <ionic@ionic.de> To: Andrew Munn <andrew@nmedia.net> Cc: x2go-user@lists.x2go.org Subject: Re: [X2Go-User] can't connect to session
- On 01/22/2018 10:28 PM, Andrew Munn wrote:
Thanks! I've added the following line to /usr/lib/tmpfiles.d/tmp.conf
x /tmp/.x2go-*
Hopefully that fixes it.
Then again, according to https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-...
and the general file system hierarchy, /usr/lib is not a good place to make changes.
Thankfully you should be able to move this into /etc/tmpfiles.d/x2go.conf and have that setting persist between system updates.
Do you think there should be some automated process to append that line during installation on a CentOS/RHEL system?
Yes, I should add this file to the general packaging! It's impressive how many workarounds are necessary for systemd in order for it not to break everything...
Mihai
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-- 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
Is okay. That's what we have facebook for :0-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Wed, 24 Jan 2018, Stefan Baur wrote:
Date: Wed, 24 Jan 2018 08:43:20 +0100 From: Stefan Baur <X2Go-ML-1@baur-itcs.de> To: x2go-user@lists.x2go.org Subject: Re: [X2Go-User] can't connect to session
*ahem*
I am one of the list-admins, and as much as I loathe SystemD, I would like to remind *everyone* reading this that having a love/hate SystemD thread on here is bound to end in a flamewar, so let's stop here before this ends in chaos.
Thank you.
Kind Regards, Stefan Baur
PS: Robert, your tone was civil, so don't take this as personal criticism or public shaming, it's a general reminder to *everyone*.
Am 24.01.2018 um 08:36 schrieb Robert Dinse:
Yes, you gotta love systemd. There is an upside though, it's about two seconds between the time my BIOS fires off the boot block and I've got a desktop login screen, under the old start up system it was more like 30 seconds.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Wed, 24 Jan 2018, Mihai Moldovan wrote:
Date: Wed, 24 Jan 2018 07:36:24 +0100 From: Mihai Moldovan <ionic@ionic.de> To: Andrew Munn <andrew@nmedia.net> Cc: x2go-user@lists.x2go.org Subject: Re: [X2Go-User] can't connect to session
- On 01/22/2018 10:28 PM, Andrew Munn wrote:
Thanks! I've added the following line to /usr/lib/tmpfiles.d/tmp.conf
x /tmp/.x2go-*
Hopefully that fixes it.
Then again, according to https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-...
and the general file system hierarchy, /usr/lib is not a good place to make changes.
Thankfully you should be able to move this into /etc/tmpfiles.d/x2go.conf and have that setting persist between system updates.
Do you think there should be some automated process to append that line during installation on a CentOS/RHEL system?
Yes, I should add this file to the general packaging! It's impressive how many workarounds are necessary for systemd in order for it not to break everything...
Mihai
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-- 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
- On 01/24/2018 08:36 AM, Robert Dinse wrote:
Yes, you gotta love systemd. There is an upside though, it's abouttwo seconds between the time my BIOS fires off the boot block and I've got a desktop login screen, under the old start up system it was more like 30 seconds.
... unless you suddenly find yourself in the never-ending cylon eye situation (ask Stefan).
Anyway, new x2goserver builds (minus FC26, since there's a problem with upstream's metadata it seems) now feature a /etc/tmpfiles.d/x2goserver.conf file on systems using systemd.
Hope that will protect session data from now on.
Mihai
-
Andrew Munn -
Mihai Moldovan -
Robert Dinse -
Stefan Baur