Re: systemd-user, daemons, and ssh sessions

On Sun, 26 Jul 2026 at 16:23:06 +1000, Russell Coker wrote:
>Currently we have the X login programs (sddm, gdm3, and probably others) using
>systemd to create a session via /etc/pam.d/common-session which if there is a
>typical desktop environment installed includes pipewire and on a laptop it
>will include Bluetooth.  While it is easy to imagine some uncommon situations
>where those things could be useful for X login (bluetooth keyboard? audio
>screen reader?) in most cases it won't be needed.

In the cases where these things *are* needed (like a machine whose only 
keyboard/mouse/input devices happen to be connected via Bluetooth, or a 
machine whose main user needs a screen reader and therefore audio), they 
are not just useful, they are essential, so a universal operating system 
will tend to need to err on the side of them being enabled.

>For ssh on a system where you have a desktop environment installed all the
>desktop programs that are started by systemd-user are run on a ssh login by
>default.

By "desktop programs", do you mean per-user services that don't require 
a desktop environment or a graphical session? Like `dbus-daemon 
--session`, which is a communication mechanism that per-user things can 
use to talk to each other, and has nothing that inherently requires a 
GUI?

For some user-services (generally "infrastructure" ones like the 
dbus-daemon), it's intentional that they run in all login sessions, 
whether those sessions are graphical, ssh, getty/login or something 
else. Historically, the dbus-x11 package had the bug that D-Bus was only 
available in graphical sessions, because there was no good way to scope 
the `dbus-daemon --session` instance to the lifetime of a session. 
One of the purposes of dbus-user-session is to fix that bug.

For other user-services, if they genuinely only make sense to run inside 
a graphical session, ideally they could have 
WantedBy=graphical-session.target or 
WantedBy=graphical-session-pre.target instead of WantedBy=default.target 
in the "[Install]" sections of their systemd service files. Some 
services like gnome-keyring already do this. (But beware of assuming 
that something is never useful for non-graphical sessions just because 
*you* don't use it in non-graphical sessions!)

Unfortunately, many of our graphical desktop environments don't interact 
with graphical-session{,-pre}.target - I know that GNOME and KDE Plasma 
do, but many others don't - and so far I haven't been able to find good 
documentation with practical advice on a minimal level of integration 
for desktop environment implementors. As a result, there is no 
particularly good way for the systemd infrastructure to choose different 
sets of services for a non-graphical session (ssh or getty/login), vs. a 
graphical session like e.g. MATE that doesn't start 
graphical-session.target. This leads many developers of 
non-desktop-environment-specific services to connect them to 
default.target instead, because that's the only thing that'll work in 
all GUI environments. If someone wants to work on addressing that 
(documenting what's expected better, and/or implementing that in other 
desktop environments) then that would be very useful, and would also fix 
some issues seen in e.g. xdg-desktop-portal.

Other user-services are started on-demand when first used, by D-Bus 
activation or socket activation or some similar protocol. If those are 
starting unexpectedly, it means something in your session is trying to 
interact with them, and the route to follow would be to find out what is 
interacting with those services, and if appropriate, make it not do 
that. For example, for D-Bus services, the reference dbus-daemon logs a 
message to the systemd Journal every time it carries out activation 
(starting a service on-demand), which mentions which program sent the 
message that requested activation.

     smcv