[X2Go-Dev] Bug#708: x2gosqlitewrapper.pl reports "unable to open database" on session-resume, while the database is there.

[Zuck, Daniel]

Package: x2goserver
Version: 4.0.1.15

Hello

The environment ist:
x2goagent: 3.5.0.27
x2goserver: 4.0.1.15
x2goserver-compat: 4.0.1.15
x2goserver-extensions: 4.0.1.15
x2goserver-fmbindings: 4.0.1.15
x2goserver-printing: 4.0.1.15
x2goserver-pyhoca: 4.0.1.15
x2goserver-xsession: 4.0.1.15
running on SLES11SP3. We have several servers running X2go, where at two systems a session resume raises an error since the same day:

DBD::SQLite::st execute failed: unable to open database file at /usr/lib/x2go/x2gosqlitewrapper.pl line 320.
syslog: invalid level/facility: error at /usr/lib/x2go/x2gosqlitewrapper.pl line 323

The message is shown by the X2Go-Client on a reconnect, right before the "session-status-info-window" becomes visible. Now at the GUI "Suspend Session" (in German: Anhalten) is selected, after this a reconnect to the session to resume. On clicking "Suspend Session", the error message is shown again. Then the session is selected and "klicked", which results in a "normal" resume of the session, and the remote GUI becomes visible.

The Syslog however has entries which read like the session is suspended/resumed correctly without any issues:

Dec 19 10:15:35 mxxxxxxxxx02 /usr/bin/x2gosuspend-session: session with ID XYZAB-76-1417681012_stDGNOME_dp32 has been suspended successfully
Dec 19 10:16:30 mxxxxxxxxx02 /usr/bin/x2gosuspend-session: session with ID XYZAB-76-1417681012_stDGNOME_dp32 has been suspended successfully
Dec 19 10:16:39 mxxxxxxxxx02 /usr/bin/x2goresume-session: client 10.43.142.67 has successfully resumed session with ID XYZAB-76-1417681012_stDGNOME_dp32
Dec 19 10:16:49 mxxxxxxxxx02 /usr/bin/x2gosetkeyboard: Setting X keyboard according to /home/XYZAB/.x2go/C-XYZAB-76-1417681012_stDGNOME_dp32/keyboard

Investigating further: When calling "x2golistsessions_root", the script lists a number of states, including the error-message above. So it appears to me, there is a consistency issue with the SQLite-DB. I strongly assume, it can be worked-around by recreating the DB, but I would like to sort out the reason, why it came to this status.

My questions:
Is this issue known? - I did not find anything like this at the bugtracker.
What information is needed for further investigations? - The system is still in this state, so we can pull further infos.

Regards

Daniel Zuck

SIX
DGI-OIE
Hardturmstrasse 201
Postfach
8021 Zürich

T +41 58 399 23 56 

http://www.six-group.com
mailto:Daniel.Zuck at six-group.com

The content of this e-mail is intended only for the confidential use of the person addressed. 
If you are not the intended recipient, please notify the sender and delete this email immediately.
Thank you.