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
--
Most legends have their basis in facts.
-- Kirk, "And The Children Shall Lead", stardate 5029.5
