Old Xsession lock files somewhere?

ThinLinc
1

Hello!

I have what at first glance might look like one of the “I can’t start the Xsession” problems we see here from time to time, but this is slightly different I think.

System: AlmaLinux 9.7, patched 25-12-22, TL 4.19 for both server and clients, air-gapped with very strict control about what can be exported from the server (so no logfiles to show, sorry about that)

Symptoms: Of about 20 users, some can log in to their Xsession (gnome and gnome classic) without any issues while others get the typical error message after the initial session configuration indicating that a xsession is already running for that user. But the thing is that this happens even after the server is rebooted in a proper way! During debugging I logged in as a regular user on a freshly rebooted server without any problems, checked for other users (none), user processes apart from my own (none), sessions apart from mine (none), sockets under /tmp/.X11-unix apart from mine (none), other lockfiles that I could think of (none), any strange process running related to other users (none). Clean, empty and nothing! The other user could still not start the Xsession. Terminate old sessions box checked in the client UI. All the central log files under /var/log look clean on the way in and then nothing strange when “bouncing out”. xinit.log for the user just says that the XDG session command is executed followed by the line with exit code 0 and then tl-kdestroy.sh and so on. Just like when you already have a xsession running. But I am pretty sure there is none.

Any ideas?

Per

Edit: the users with issues used to be able to log in and start the xsession before we updated to 4.19.

2

Hi @Per,

Was this error message from ThinLinc, or from GNOME? Did you have a screenshot available?

3

Thank you for looking at this problem. It’s the screen-like face saying oops (a Gnome specific thing?) directly after the Xsession configuration. Unfortunately I can’t export anything from the system, not even screenshots, due to security related restrictions.

Per

fre 2 jan. 2026 kl. 19:10 skrev Aaron Sowry via ThinLinc Community Forum <[email protected]>:

4

Okay, thanks for the clarification. Are there any clues in the system logs? The error message you describe can occur due to being logged in at the console, but it can also be caused by other things.

5

It’s a real bummer that I can’t show the actual logs and the manager who potentially could grant a temporary permission is gone for the holidays until Wednesday. But I will try to do my best and paraphrase the relevant content:

vsmagent.log:

[redacted time stamp] …Verified connectivity to newly started Xvnc for [redacted]

[redacted time stamp + 44 seconds] …Broken session for user [redacted], tl-session process [redacted] does not exist

vsmserver.log:

[redacted time stamp] …Session 127.0.0.1:11 created for user [redacted]

[redacted time stamp + 12 seconds] …Session 127.0.0.1:11 for [redacted] has terminated. Removing.

messages:

[redacted time stamp] system-logind[1338] New session 70 for user [redacted]

[redacted time stamp + 1] systemd[1] Started Session 70 for User [redacted]

[redacted time stamp + 1] system-logind[1338] New session 72 for user [redacted]

[redacted time stamp + 1] systemd[1] Started Session 72 for User [redacted]

[redacted time stamp + 2] system-logind[1338] New session 73 for user [redacted]

[redacted time stamp + 2] systemd[1] Started Session 73 for User [redacted]

secure:

[rts + 1] sshd[…] Accepted publickey for cn=[redacted]…

[rts + 1] sshd[…] pam_unix(sshd:session): session opened for user cn=[redacted] (uid=NNN) by [redacted] (uid=0)

[rts + 10] tl-session[…]: pam_unix(thinlinc:session): session closed for user [redacted]

[rts + 11] sshd[…]: Disconnected from user cn=[redacted]…

[rts + 11] sshd[…]: pam_unix(sshd:session): session closed for user cn=[redacted]

xinit.log:

[rts + 1] [a lot of initialization using thinlinc/etc/xstartup.d]

Stopping initial window manager…

Done.

Executing profile: gnome-classic

Using XDG session: gnome-classic

Updating D-Bus and systemd environment…

Executing XDG session command: env GNOME_SHELL_SESSION_MODE=classic gnome-session

Profile command exited with exit code 0

Running […]/tl-kdestroy.sh

Running […]/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 [XXX]

tl-while-X11: lost Xserver connection, terminating child [YYY]

EncodeManager: …

.

.

.

tl-xinit: Xserver terminated and returned 0

tl-xinit: deleting ../[session number].ended

tl-xinit: Session terminated. Exiting.

6

Sorry for the long text above.

The strange thing is that some users can access the server, others not. All users used to be able to access the system before we upgraded to 4.19. The same holds for a freshly rebooted server with no active sessions at all. There is no pattern that I can find. Some of the “excluded” users use bash, others other shells. Some use gnome, some use gnome-classic. All “excluded” users have similar entries in their xinit.log. I am somewhat confused right now. Your help is much appreciated.

Per

7

@Per did you have a support agreement with us? If so, you could send the log files through to [email protected] along with your subscription ID, if that would be acceptable from a confidentiality perspective. However, there’s not anything super obvious in the excerpts posted above as to what the problem is, I’m afraid.

gnome-session seems to exit “normally” (albeit unexpectedly), so I’m not too sure what’s going on. My only guess at this point would be that there is something specific to these users (e.g. dotfiles in their home directory), which for some reason only became an issue after upgrading either ThinLinc or Alma Linux.

One thing you could try is connecting as an “excluded” user, but enter xterm under “Start the following program” in the “Advanced” tab of the ThinLinc client options. This will give you a session with only xterm running, no DE. You could then try running your DE manually from xterm and see what happens, i.e.:

$ GNOME_SHELL_SESSION_MODE=classic gnome-session

This might give you a better idea of what’s happening, and an opportunity to test a few things without having to start a new session each time.

Hope that helps!

8

Yes, we have a support agreement so I will try to wrestle some actual log files from the security overseers.

We have a local holiday tomorrow so I will try what you have recommended on Wednesday morning.

Per

mån 5 jan. 2026 kl. 19:22 skrev Aaron Sowry via ThinLinc Community Forum <[email protected]>:

9

Perfect! Let’s take it from there, then :slight_smile: