What does pam_systemd.so do?

Question

I switched my SD card from the fast RaspberryPi 4 to the RaspberryPi 2. Now, logging into it with ssh -vv took about 3 minutes and got stuck at pledge: network. This question discusses such behaviour and my solution was to comment out session optional pam_systemd.so in /etc/pam.d/common-session.

But I would like to know what this actually does. I understand that it is related to openening a user-session but I am not familiar with why it is important.

My journalctl | grep pam shows this:

Dec 29 15:59:07 RPi4 sshd[1392]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 29 15:59:08 RPi4 systemd: pam_unix(systemd-user:session): session opened for user admin by (uid=0)
Dec 29 16:02:01 RPi4 sudo: pam_unix(sudo:session): session opened for user root by admin(uid=0)
Dec 29 16:02:01 RPi4 sudo: pam_unix(sudo:session): session closed for user root
Dec 29 16:02:23 RPi4 sudo: pam_unix(sudo:session): session opened for user root by admin(uid=0)

Answer 1

pam_systemd is the plug-in that makes the difference between the classic (pre-systemd) login process and the systemd-aware one.

Without it, the login process works as it did with SysVinit: if a user process daemonizes (i.e. closes its standard input, output & error streams, forks twice, then has the child process die leaving the grandchild an orphan, reparented to UID #1 by the kernel), there will be no way to track which session it belonged to. Instead of the entire login session and all its children being reliably encapsulated into a separate control group, all the processes go into the common pile. So the enforcement of per-session resource limits can't be done either.

Also, the user run-time directory /run/user/<UID>/ won't get created, which might disable some features of some desktop environments, and things that attempt to be multi-session friendly like GnuPG Agent for example. And last but not least, the user@<UID>.service system service and any per-user systemd services managed by it will not be started: there will be no session D-Bus for this user/session, nor Pulseaudio. See systemctl --user (in a system with a working per-user systemd services).

At logout, without pam_systemd being in play, the logout process won't be able to cleanly enforce that all the processes of the user session are definitely cleaned up at end of session (should the system administrator wish so; see KillUserProcesses= in logind.conf(5)).

You'll also lose a simple way to plug in non-root actions to events like your user login/logout, or non-root actions conditional to things like filesystems being mounted or hotpluggable network/storage/bluetooth/other devices being present or appearing later during the login session.

If your goal is a lean, mean single-task machine, you might regard this as a successful amputation of a lot of unnecessary stuff; but depending on your goal, you might not.

Anyway, the question you referred to indicates the problem might be caused by something causing the system D-Bus to restart, which would require restarting systemd-logind and possibly other system services that depend on the system D-Bus.

The root cause for your login slowness problem might also have been something like Pulseaudio being still configured to expect RasPi 4 hardware and being confused on not finding it.

Background:

On a systemd-based installation, there may be at least two relevant instances of D-Bus for each user session: a system D-Bus that enables selective passing of system-wide status information and control as configured by polkit, and a session D-Bus for user-level things. Some GUI desktop environments may fire up a small extra D-Bus instance or two for handling accessibility and/or internationalization (input methods for Chinese/Japanese/Korean characters and similar).