On 20/01/2026 00.42, Elias Oltmanns wrote:
Even loginctl can be fooled up to a point it seems. Switching away from
a running Wayland session to the text console on tty2, the output of:
$ loginctl session-status
is as expected: Session type=tty, tty=tty2, state=active, and
Unit=session-4.scope. Next, I launched the multiplexer tmux on tty2 and
ran:
$ loginctl session-status
again. This time, it reported session type=wayland, tty=tty1,
state=online, and Unit=session-5.scope. According to the man page,
loginctl should have reported the status of the „current session“ in
both cases but in the latter case it seemed to have an odd idea what the
current session would be.
That's normal in this case, as your tmux (or Screen) windows *aren't*
necessarily running in the terminal where you attached them from. It's
part of the whole 'feature' of tmux.
Traditionally they used to be running under the tmux server process,
which (even for newly started tmux "sessions") is running in background
wherever you invoked tmux first – the same tmux server is then reused
for all new sessions and you're effectively just seeing a "remote
control" view of it, so if the server got started in session 1
everything would have been in session 1.
But newer tmux versions split out each pane into its own systemd .scope
unit: they still inherit the environment from tmux but get moved into
new cgroups directly under 'systemd --user' and therefore [1] no longer
running "in" any session anymore (as the whole of 'systemd --user' is
outside of all sessions). The same is done by GNOME Terminal and
Ghostty, too.
[1] In most cases your logind session membership is derived from your
cgroup, as in /proc/self/cgroup, so see `systemd-cgls` (or the subtree
in `loginctl user-status`). It's not derived through any environment
variables like it used to be in ConsoleKit
So I think it might be that logind now implicitly associates "systemd
--user" – or maybe even all of the user's non-session processes – with
the first (and only) session of that user that has CanGraphical=yes,
though I don't remember when that change was made. (I do recall that
Policykit got this change first, but I no longer keep up with
systemd.git as closely as I used to.)
(This whole thing has a slightly messy timeline: from what I remember,
back when logind sessions were first introduced to supersede ConsoleKit,
the concept of a dedicated out-of-session "user service manager" did not
yet exist – originally "systemd --user" was just something you could run
from *within* a session; I used to start it from my .xinitrc as a
supervisor for wmii.
And later it got turned into a standalone thing that was advertised to
be purely for background tasks at that time (still managed through a
dedicated control socket), but some of those background tasks needed
D-Bus, and somehow the 'user bus' absorbed the 'session bus' to
centralize on XDG_RUNTIME_DIR, and naturally bus-activated apps got
launched under that 'user' dbus-daemon, which now suddenly had to learn
about session-specific environment variables... and gradually the whole
of a graphical session migrated under systemd --user.)
