I found this bug report from Cendio, relevant to my ongoing experiments with ThinLinc.
@samuel initially suggested using the info returned by loginctl list-sessions for detecting potentially conflicting sessions (see comment 18). I understand that you’ll be implementing this differently, but can you clarify the logic you intended to apply on the info obtained from loginctl?
Thanks!
Hey @JBL,
As it looks right now, we’ll be using libsystemd (statically linked) directly to grab information regarding currently existing sessions (instead of calling loginctl). With this information in hand, we replicate the behavior of modern GDM to inform users that a “conflicting” session is already running. That’s how it looks right now, at least.
Note that we won’t be doing any such checks if multisession is turned on (i.e. /vsmserver/max_sessions_per_user != 1). We are also trying to avoid making systemd a hard dependency.
Do you have any more information to share about your current experiments? Niche questions like this generally pique our interest 
.
Thanks @wilsj, that’s indeed what I recall from reading the rest of the bug report.
What I’m really after is the equivalent logic using loginctl instead (or anything else I can access from the terminal), so I can get a sense already today for what will formally qualify as a problematic setup in the future (i.e. a situation with those “conflicting” sessions).
I’m currently trying out variations of the approach suggested in this blog post on a Fedora 43 + i3wm workstation. It looks promising, but I suspect everything I’ve tested so far involves conflicting sessions. So if I can get more details about how you initially intended to use the loginctl info to detect conflicting sessions, I could be more certain, and maybe derive a more robust setup based on those rules.
(I guess an easy way to stay out of trouble would be to create a user exclusively for ThinLinc access, but I’m hoping there’s a more elegant solution.)
Hi, @JBL!
More specifically, we are checking if there are any sessions belonging to a given user that have their Type-property set to one of [x11, wayland, mir], this is similar to what GDM does to check if a session is a graphical session.
With loginctl you could run loginctl show-session <sessnum> --property=Type --value and check its output.
Hope that helps! 
Thanks @Zeijlon , that’s what I was after.
So put in another way: for the approach suggested in the Cendio blog post to “pass” the upcoming multiple session test (and without resorting to set up multiple user accounts for the same physical user), no display manager or desktop environment / window manager can be in use when the ThinLinc session starts. Correct?
Yes, that’s correct!
Just to follow up: I think there might be scenarios where the suggested logic won’t catch an X session in disguise.
For example if I disable the display manager and use startx + .xinitrc to start a local X session, even if I prepend exec /usr/bin/i3 with export XDG_SESSION_TYPE=x11 (to make applications that look at this variable happy), loginctl will report my session as a tty type.
That shouldn’t be a problem if I swap i3 for tlclient though: the ThinLinc agent will then start it’s own local X session, that will be reported as an x11 type. (And one doesn’t even need to mess with XDG_SESSION_TYPE in that case: it will be set to x11 and that’s what the ThinLinc clients will see.)
Based on what I’ve heard around the Cendio office, the scope was to build something that’s able to detect (and optionally terminate) running sessions in the majority of cases. In this case, that means assuming that the graphical session is started through systemd, which will be the case for sessions started both by ThinLinc and modern display managers.
Naturally, there are ways to circumvent this check. Our belief is that this should be relatively rare in production environments though. Please @Zeijlon, correct me if I’m wrong!
Fair enough @wilsj , thanks!
I don’t think we are actually starting our ThinLinc sessions through systemd, but we are for sure doing something to make our sessions visible to logind. I just wanted to add this clarification since we currently do not have a hard dependency on systemd. It’s possible to run a ThinLinc server on a non-systemd system.
That is actually fine! The main reason for adding the check is that we want to improve the user experience for new/novice users that are testing out ThinLinc for the first time.
Gnome and some other DEs don’t work well in a multi-session context, and we would like to avoid creating broken sessions when, for example, a user is testing ThinLinc on their local machine.
I don’t think we are actually starting our ThinLinc sessions through systemd, but we are for sure doing something to make our sessions visible to logind.
On most systems, this is the responsibility of the session stack in PAM (by including pam_systemd.so).