Description of problem: "systemd --user" instance is useful for tty sessions only, not for sftp or ftp sessions. Currently, since the spawning is performed by pam_systemd, every single PAM aware service sourcing pam_systemd (usually because it includes password-auth) will see a "systemd --user" instance being spawned. This makes the system perform poorly when it's designed to serve many requests from outside world, e.g. it hosts a ftp service implemented by vsftpd. The available workarounds are not convenient at all: Workaround 1: Disable user@.service globally. Impact: GUI sessions are not possible anymore Workaround 2: De-duplicate the PAM stack and remove "pam_systemd" for the service not needing "systemd --user", but then cgroup creation is not performed anymore Version-Release number of selected component (if applicable): systemd-239-41.el8_3.1.x86_64 How reproducible: N/A
Whether pam_systemd.so is included in the setup of the PAM session depends entirely on the PAM configuration. In order to prevent launching systemd --user instances when it is not desirable we should fix the appropriate PAM configuration files. Also this RHEL-8 change should be coordinated with corresponding authselect changes so that we have the same behaviour in recent Fedoras and in RHEL-9.
I'm sorry for the ping pong, but lets switch the component back to systemd. We could fix this in pam/authselect and omit pam_systemd for some services, but the same can be done in pam_systemd itself - be a noop for services where it does not make sense to run it. This would be much better choice since from pam point of view, we can not decide (and guarantee) which services are valid for pam_systemd and which are not. It would be also safer for the future as only pam_systemd would need to be changed if the list of irrelevant services changes.