Re: systemd-user, daemons, and ssh sessions

Moin

On Sun, Jul 26, 2026 at 04:23:06PM +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.

gdm3 tears down unused greeter sessions within a minute.  So no, this
does not run unused.  Both bluetoothd (which runs outside of the user
session as root anyway) and pipewire are required for a useful greeter.

> 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.

No, as at least gdm3 does not start anything, but just sets up a systemd
user session for the greeter.

> 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.

systemd-user runs once for a user, but logins (ssh or local) cen be
multiple.  So how would you distinguish that?

> 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?

I fail to see a goal.  Maybe describe that first.  And no, excluding
pam_systemd will break a lot of stuff.  You can try this yourself by
logging into a user with uid between 1 and 999, which are excepted from
user session.

Bastian