Home / server / Questions / 1166803
Accepted
David C
Asked: 2024-10-19 21:12:42 +0800 CST

systemd --user & sd-pam Processes Never Stop

  • 772

This started after installing Google Chrome (for headless browser functionality). I am concluding it has something to do with Chrome. For the first few hours after install, I was building a short-running script calling Chrome in a remote browser.

2 sides to the question. Is it acceptable for systemd to continuously run, and if so, how can the alerts be suppressed?

I have been receiving the below reports for days for the 2 reseller accounts (4 total every hour). Notice the process time is in the "days".

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: (sd-pam)
PID:          35343 (Parent PID:35342)
Killed:       No

and

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: /lib/systemd/systemd --user
PID:          35342 (Parent PID:35342)
Killed:       No

After adding the following 4 lines to csf.piginore and restarting LFD, the alerts are still coming.

pcmd: /usr/lib/systemd/systemd
pexe: /usr/lib/systemd/systemd
cmd: (sd-pam)
cmd: /lib/systemd/systemd --user

** Edit ** adding images for grawity's answer.

loginctl status

systemctl status user@

systemd

2 Answers

  1. The 'systemd --user' process belongs to user@<uid>.service (which you can find out using systemctl status <pid>). Its entire purpose is to host user-level services, so it indeed runs for the entire duration that a user is logged in (in the sense of having an active SSH session or something equivalent).

    By default it is automatically started when the user logs in, and stopped a few moments after that user completely logs out, but it could in theory also be started by other causes. It is up to you to decide whether to limit its runtime, or to disable it outright.

    Run loginctl to check whether there are actually any login sessions associated with that user, or loginctl status <user> to see the user's process tree (including systemd --user). Sometimes sessions could be in an abandoned state where they technically have been closed but still have processes (like when you run something with 'nohup' and then exit SSH).

    Also run systemctl status user@<uid> to see only the process tree of 'systemd --user' (including all sub-units that it manages). If you don't see any reason for it to be stuck running – no login sessions, no user-level services – you can technically systemctl stop the service or kill the process in the regular way.

    • 1
  2. Best Answer

    u1686_grawity's answer helped me track down the issue, because it opened up systemctl and loginctl for me. There were several trial-and-error attempts involved before reaching a conclusion outlined here.

    The solution seems to be in the configuration values in /etc/systemd/logind.conf. When I first checked the VPS with Debian 11 had all the keys in this file commented out. I eventually uncommented these:

    KillUserProcesses=yes
UserStopDelaySec=10

    and after a reboot, the tiresome, hourly CSF process alert messages stopped and loginctl was no longer showing a bunch of sessions (processes) for the users on the system.

    As a side note,

    # systemctl --version
systemd 247 (247.3-7+deb11u6)

    does not include the key StopIdleSessionSec=, which might have also fixed the failing to logout user sessions.

    Note: For Debian systems the config file keys are explained here: logind.conf - systemd - Debian Manpages

    • 0