Home / server / Questions / 1171943
Accepted
Richlv
Asked: 2025-01-30 20:53:16 +0800 CST

Services started in user slice, "systemd --user" and "(sd-pam)" remain running

  • 772

Observed some systemd related processes never stopping. Investigating, they are connected to Java-based services, potentially caused by those being started up manually via su.

$ sudo loginctl user-status username
username (1014)
           Since: Tue 2025-01-28 04:03:56 CST; 2 days ago
           State: closing
        Sessions: 100
          Linger: no
            Unit: user-1014.slice
                  ├─session-100.scope
                  │ ├─1037532 bash /some/script
                  │ ├─1037541 /usr/lib/jvm/jdk/bin/java -parameters
                  │ ├─1039230 /usr/java/default/bin/java -parameters
                  │ ├─1039510 /usr/java/default/bin/java -parameters
                  │ └─1056980 /usr/java/default/bin/java -parameters
                  └─[email protected]
                    └─init.scope
                      ├─1007530 /usr/lib/systemd/systemd --user
                      └─1007534 (sd-pam)

While the systemd processes not stopping is similar to systemd --user & sd-pam Processes Never Stop , here the shared slice seems to be more of an interest.

a) Does the services being attached to the user slice mean they would potentially share resource limits with that user, not the service account?

b) Are there any other implications from the services running in the user slice?

c) Are there any reasonable workarounds to prevent this from happening, besides using proper startup scripts / systemd services?

Edit: just to clarify, I observed this after the actions of other users. Personally, I've clashed with people on not becoming other users for at least 10 years by now :)

systemd

1 Answers

  1. Best Answer

    Does the services being attached to the user slice mean they would potentially share resource limits with that user, not the service account?

    Yes. All cgroup-based limits (task, memory, IO, CPU...) will be shared with the user whose slice/cgroup it's in.

    Are there any other implications from the services running in the user slice?

    The implication is that good practices are not being followed – you started the service by hand from SSH, so that 1) it is not monitored for crashes/restarts, 2) whenever the server is rebooted, it will be down until restarted manually and 3) will have to be restarted using a nonstandard procedure that the sysadmin will need to figure out, 4) depending on the procedure it may have inherited things like environment variables or SELinux contexts from whichever user started it, and 5) it might be subject to systemd's "kill processes belonging to logged out users" feature if your distribution ever enables it – or if you ever decide to enable it locally forgetting about the "services" it would affect.

    Are there any reasonable workarounds to prevent this from happening, besides using proper startup scripts / systemd services?

    Really, use a systemd service.

    If you haven't written a .service unit yet:

    The systemd-run command can be used to start a "transient service" with all parameters specified via command line – its output can optionally be attached to your terminal with --pipe if you're running it this way for debugging, but in all other respects it runs in a service-like environment (started from PID1, has its own "service" cgroup instead of sharing the user's cgroup, etc).

    • 3