Hello,
The day after, I can testify that changing the power-saving settings on the server prevented this issue to rise again. I don't know if it's worth writing that somewhere in a FAQ but for the record, I wanted to write it here at least.
Have a nice day.
Nicolas
Le 29/09/2020 à 11:49, Nicolas Ecarnot a écrit :
Hello,
Ulrich und Stefan, danke für Ihre Antwort,
Please read below.
Le 28/09/2020 à 22:25, Stefan Baur a écrit :
I don't know if I could run the client and/or the server with additional verbosity to try to get more hints? x2goclient --debug >~/x2godebug.log 2>&1 On the server, you can edit /etc/x2go/x2goserver.conf and replace loglevel=debug This will increase the verbosity of x2goserver's syslog entries.
Ok, I added those two verbosity parameters, and though it does tells me tons of additional things at start, they then keep quiet so far. I noticed that the "no click" issue is appearing some times after a inactive moment, so that could confirm Stefan's feeling about some power saving actions...
This morning, I ran the usual setup, just adding the verbose setup described above, and let it sleep until the "no click issue" arose. In the logs, I saw nothing at all. Not a line, nothing.
Does that look like something familiar?
You are actually the third to encounter this issue; sadly, the other two couldn't be bothered to subscribe here to report the bug.
It seems to be a server-side issue, using Ubuntu 20.04 on the server side is the common part of the reports.
I wonder if maybe there's some kind of sleep/suspend/energy-saver at work, or maybe some kind of "scrubbing" mechanism (possibly systemd-related)?
The server machine is a vmWare VM, and I checked in some advanced vmWare specific settings whether there could be something relevant but I found none. Using the vmWare remote console ("vmrc"), I logged in and disabled every sleep/suspend/energy-saver related parameters I could find. Then I killed my session and restarted.
I could be too soon to tell, but it's been more than half an hour, and so far, the issue has NOT come back.
It's disturbing because the energy-saving parameters I changed were made as a user and not as root, so I don't get why it could improve a system-wide behaviour?
I've seen such issues in the past, in different contexts, where cron jobs were unaware of a running X2Go session and did "stupid" things (like shutting down the server) that affected the session - because to them, it looked like there are no users logged in.
I checked what cron could have be doing recently but I found nothing I could blame it for.
Do you think you could set up a test server with Ubuntu 20.04 that does not have a GUI, and only some very basic X applications like xterm?
Of course I could. At present, I'm just letting my server some more time to determine whether the issue has gone or not. If still present, I'll try your suggestion.
Is gdm (or some other graphical login manager) running on your server? If so, could you stop it, switch the machine to text-only mode, and see if that makes a difference?
-Stefan
The server is an XUbuntu 20.04, so the default login manager is LightDM, and the wm is XFCE. If needed, I could try to start it with no X at all and keep testing.
Stay tuned, more to come.
Have a nice day.
-- Nicolas Ecarnot