ThinLinc server not working correctly on Ubuntu 23.10 after update

Hi there

I am running ThinLinc on an Ubuntu server, version 23.10. I’m aware this isn’t an LTS release and so probably isn’t supported, but I wanted to post anyway and see if I could figure out the issue.

Up until today, the ThinLinc server has been working fine. I updated the server and shut it down to replace the UPS. On restart, ThinLinc no longer works. I’ve updated to 4.16 but it has made no difference.

The issue manifests as:

  1. Log in with the ThinLinc client - this works ok
  2. I’m presented with the startup GUI dialogue, and I press Start as usual
  3. The progress bar moves along, and I see ThinLinc starting the various components. It looks like it gets to completion and the point where it would normally switch to the desktop.
  4. Instead, the session closes and I get an error saying that the session lasted less than 10 seconds and if I didn’t log out then to contact my system administrator.

I’ve had a look in the vsm*.log and tl*.log files in /var/log but can’t see any errors or messages that seem related. I’m presuming a package update has caused the issue but I’m not sure which one it is.

What is a good way to debug this and figure it out - I’d love to get ThinLinc working again, especially with the 24.04 LTS release coming up.

Thanks in advance!

Heya,

What were you updating from, or was it just patches to an already functioning 23.10 system?

Let’s have a look at the session log file, located in /var/opt/thinlinc/sessions//last/xinit log

Regards,
Martin

Hey!

Good point - it was just patches to an already functioning 23.10 server so in theory nothing major. Also the GUI is working fine if I connect a display to the server, so the X server and XFCE are starting ok, at least for physical console users.

I checked the log file you mentioned - most of it looks normal until the end, when I see:

Session PulseAudio server started. Redirecting applications...
Running /opt/thinlinc/etc/xstartup.d/50-tl-wait-smartcard (Waiting for smart card connection)
Stopping initial window manager...
Done.
Executing profile: xfce
Using XDG session: xfce
Updating D-Bus and systemd environment...
Executing XDG session command: startxfce4
/bin/startxfce4: X server already running on display :10
xfce4-session-Message: 15:27:31.630: GNOME compatibility is enabled and gnome-keyring-daemon is found on the system. Skipping gpg/ssh-agent startup.
discover_other_daemon: 1Profile command exited with exit code 0
Running /opt/thinlinc/etc/xlogout.d/tl-kdestroy.sh
Running /opt/thinlinc/etc/xlogout.d/tl-umount-localdrives
tl-xinit: client terminated and returned 0
tl-xinit: Terminating X server...
X I/O error
tl-while-x11: lost Xserver connection, terminating child 457638 ...
tl-while-x11: lost Xserver connection, terminating child 457649 ...

Thu Mar  7 15:27:31 2024
 VNCSConnST:  closing 127.0.0.1::62606: Server shutdown
 EncodeManager: Framebuffer updates: 149
 EncodeManager:   CopyRect:
 EncodeManager:     Copies: 7 rects, 84.44 kpixels
 EncodeManager:             112 B (1:3016.46 ratio)
 EncodeManager:   Tight:
 EncodeManager:     Solid: 89 rects, 1.29944 Mpixels
 EncodeManager:            1.39062 KiB (1:3650.87 ratio)
 EncodeManager:     Bitmap RLE: 43 rects, 11.773 kpixels
 EncodeManager:                 1.30176 KiB (1:35.7149 ratio)
 EncodeManager:     Indexed RLE: 96 rects, 90.09 kpixels
 EncodeManager:                  17.9893 KiB (1:19.625 ratio)
 EncodeManager:   Tight (JPEG):
 EncodeManager:     Full Colour: 206 rects, 800.662 kpixels
 EncodeManager:                  681.384 KiB (1:4.59359 ratio)
 EncodeManager:   Total: 441 rects, 2.28641 Mpixels
 EncodeManager:          702.175 KiB (1:12.7268 ratio)
 ComparingUpdateTracker: 1.22082 Mpixels in / 1.01571 Mpixels out
 ComparingUpdateTracker: (1:1.20194 ratio)
tl-xinit: Xserver terminated and returned 0
tl-xinit: deleting ../10.1709756490.ended
tl-xinit: Session terminated. Exiting.
(END)

Would the terminating Xserver messages be responsible?

Would you mind creating a new local account and test if launching a session works ?

Regards,
Martin

Thanks @martin! That was a good call - I created a new user and the session works.

So question is, what do I need to tweak/reset for my own session to work?

James

Has any of your dot-files been modified recently?

Not recently, no. I used to run TigerVNC on this server but I’ve shut that down in favour of ThinLinc now. I found that the .vnc directory was still in my home directory so I’ve move that aside. I retried the connection but the same error (though not sure if I should be restarting any services?).

A bit more log analysis here. I’ve compared the log files for the new test user account and the account that is failing. The files look similar up until this point here (extract taken from the failing account):

/bin/startxfce4: X server already running on display :11
xfce4-session-Message: 14:45:53.179: GNOME compatibility is enabled and gnome-keyring-daemon is found on the system. Skipping gpg/ssh-agent startup.
discover_other_daemon: 1Profile command exited with exit code 0
Running /opt/thinlinc/etc/xlogout.d/tl-kdestroy.sh
Running /opt/thinlinc/etc/xlogout.d/tl-umount-localdrives
tl-xinit: client terminated and returned 0
tl-xinit: Terminating X server...
X I/O error
tl-while-x11: lost Xserver connection, terminating child 955054 ...
tl-while-x11: lost Xserver connection, terminating child 955067 ...

Both sessions attempt to run startxfce4 but from there the log messages diverge. I do not see the GNOME compatibility warning on the working account. I also don’t see the tl-kdestroy.sh or tl-ummount-localdrives.sh run on the working account.

The could be misleading of course, but it seems to be somewhere around this part of the log file that things go wrong for the broken account. Does this help at all? Happy to share the full log files if that helps.

No, thats missleading. I would start by moving your .bashrc to a backup location and copy one of /etc/skel to your $HOME and see if that makes a difference. Something in your home folder is probably messing something up with launching the Xnc session

Thanks to your help the issue is fixed, but I’m not exactly sure which step fixed it. That might sound odd, but when I brought the server back online after the UPS replacement, I needed to get it back online quickly. When I couldn’t log in with ThinLinc, I’d logged onto the local GUI using the iDRAC remote console, and completely forgotten that I’d left that logged in.

As soon as I logged out the session on the iDRAC console, the ThinLinc connection started working again, so one of the interim steps must have fixed the original issue but I needed to also log out of the existing console session for it to work.

As an aside, is it expected that you can’t log in on both a ThinLinc remote session and a local console session? If this is by design then that’s fine, but I hadn’t noticed this before - though I’ve never explicitly started testing it in detail until today!

Aha! Good catch.

This is not a limitation of Thinlinc, but rather how the whole ecosystem in Linux has evolved. Running multiple graphical sessions as the same user account will behave poorly, if at all. For example, Dbus assumes one session bus per user, launching another could lead to unexpected behavior with inter-process communication.

Hope everything is as expected now :slight_smile:

Regards,
Martin

Yes all perfect - thanks so much Martin!

1 Like