[X2Go-User] Losing mouse click ability and keyboard events

[Nicolas Ecarnot]

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