# Upcoming solution for detecting multiple sessions?

**URL:** <https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852>\
**Category:** Community Support\
**Tags:** admin, thinlinc\
**Created:** [2 February 2026 08:06 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852 "2026-02-02T08:06:53Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![JBL](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/jbl/32/1341_2.png) [@JBL](https://community.thinlinc.com/u/JBL)\
**Post date:** [2 February 2026 08:06 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/1 "2026-02-02T08:06:53Z")

</div>

I found this [bug report](https://bugzilla.cendio.com/show_bug.cgi?id=8401) 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](https://bugzilla.cendio.com/show_bug.cgi?id=8401#c18)). 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!

---

<div class="post-metadata">

**Author:** ![wilsj](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/wilsj/32/554_2.png) [@wilsj](https://community.thinlinc.com/u/wilsj)\
**Post date:** [2 February 2026 12:27 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/2 "2026-02-02T12:27:12Z")

</div>

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 😉.

---

<div class="post-metadata">

**Author:** ![JBL](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/jbl/32/1341_2.png) [@JBL](https://community.thinlinc.com/u/JBL)\
**Post date:** [2 February 2026 16:14 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/3 "2026-02-02T16:14:08Z")

</div>

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](https://www.cendio.com/blog/linux-is-just-not-ready-for-remote-desktop-we-agree-and-disagree/) 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.)

---

<div class="post-metadata">

**Author:** ![Zeijlon](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/zeijlon/32/1046_2.png) [@Zeijlon](https://community.thinlinc.com/u/Zeijlon)\
**Post date:** [3 February 2026 08:59 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/4 "2026-02-03T08:59:56Z")

</div>

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! 😄

---

<div class="post-metadata">

**Author:** ![JBL](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/jbl/32/1341_2.png) [@JBL](https://community.thinlinc.com/u/JBL)\
**Post date:** [11 February 2026 08:56 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/5 "2026-02-11T08:56:25Z")

</div>

Thanks @Zeijlon , that’s what I was after.

So put in another way: for the approach suggested in [the Cendio blog post](https://www.cendio.com/blog/linux-is-just-not-ready-for-remote-desktop-we-agree-and-disagree/) 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?

---

<div class="post-metadata">

**Author:** ![Zeijlon](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/zeijlon/32/1046_2.png) [@Zeijlon](https://community.thinlinc.com/u/Zeijlon)\
**Post date:** [13 February 2026 15:02 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/6 "2026-02-13T15:02:14Z")

</div>

Yes, that’s correct!

---

<div class="post-metadata">

**Author:** ![JBL](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/jbl/32/1341_2.png) [@JBL](https://community.thinlinc.com/u/JBL)\
**Post date:** [18 February 2026 12:14 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/7 "2026-02-18T12:14:50Z")

</div>

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.)

@wilsj @Zeijlon am I missing something?

---

<div class="post-metadata">

**Author:** ![wilsj](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/wilsj/32/554_2.png) [@wilsj](https://community.thinlinc.com/u/wilsj)\
**Post date:** [25 February 2026 15:56 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/8 "2026-02-25T15:56:04Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![JBL](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/jbl/32/1341_2.png) [@JBL](https://community.thinlinc.com/u/JBL)\
**Post date:** [26 February 2026 08:00 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/9 "2026-02-26T08:00:12Z")

</div>

Fair enough @wilsj , thanks!

---

<div class="post-metadata">

**Author:** ![Zeijlon](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/zeijlon/32/1046_2.png) [@Zeijlon](https://community.thinlinc.com/u/Zeijlon)\
**Post date:** [26 February 2026 08:34 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/10 "2026-02-26T08:34:51Z")

</div>

> [@wilsj](#):
>
> 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.

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.

> [@JBL](#):
>
> I think there might be scenarios where the suggested logic won’t catch an X session in disguise.

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.

---

<div class="post-metadata">

**Author:** ![wilsj](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/wilsj/32/554_2.png) [@wilsj](https://community.thinlinc.com/u/wilsj)\
**Post date:** [26 February 2026 13:14 UTC](https://community.thinlinc.com/t/upcoming-solution-for-detecting-multiple-sessions/1852/11 "2026-02-26T13:14:07Z")

</div>

> 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`).
