Bug 1942956

Summary: "systemd --user" instances are spawned unnecessarily, affecting system performances
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: systemdAssignee: systemd maint <systemd-maint>
Status: NEW --- QA Contact: Frantisek Sumsal <fsumsal>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.3CC: atikhono, bwelterl, dtardon, ipedrosa, msekleta, pbrezina, pdwyer, peter.vreman, pwallend, sbroz, systemd-maint-list
Target Milestone: rcKeywords: FutureFeature, Performance, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Story
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Renaud Métrich 2021-03-25 11:48:13 UTC
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

Comment 1 Michal Sekletar 2021-07-21 08:42:16 UTC
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.

Comment 4 Pavel Březina 2023-04-25 09:59:00 UTC
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.