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?