systemd-user, daemons, and ssh sessions

Russell Coker <[email protected]> Sun, 26 Jul 2026 16:23:06 +1000
Newsgroups gmane.linux.debian.devel.general
Message-ID <2017182.taCxCBeP46@dojacat>
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.

Should we make it a standard practice to have configuration options for this 
to allow the sysadmin to easily choose whether sddm/gdm3/whatever starts such 
things?  It shouldn't be THAT difficult for a sysadmin to put in symlinks in 
the account configuration for sddm to make it not start such things, but it's 
also not particularly easy.

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.  For a single user system this works well.  For a system that many 
developers ssh to but which has an X login at the console either for people to 
control it via GUI tools or because it's the default and no-one uninstalled 
those things you end up with every developer having a bunch of programs that 
they never use running all the time.

For ssh it would be good to have options to easily disable user units at a 
default level (maybe in /etc/skel) and also have a good way of disabling 
systemd in pam for a single daemon.  Sure you could edit /etc/pam.d/sshd to 
not include common-auth and then paste in the bits of common-auth you actually 
want but that's ugly and will risk errors on upgrades.

What do you think?