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
