Systemd manages user sessions by launching a per-user instance of the service manager, which handles resources allocated to that specific user. During shutdown, the system does not simply kill these units; it follows a structured sequence where PAM session termination signals are sent before the user unit itself is stopped. This ensures that applications have a chance to save state and clean up file descriptors before the underlying user namespace is dismantled.
The Role of the User Manager
When a user logs in via SSH or a local console,
pam_systemd triggers the creation of a transient user slice and scope. The core component here is the per-user
systemd --user instance. Unlike the system-wide manager that handles services like
networking or
sshd, this user manager is responsible for processes started within that session, including desktop environments, background daemons launched by the user, and temporary scopes for terminal sessions.
Understanding this separation is critical because many modern Linux distributions rely on user-level systemd instances to manage resource limits, cgroups, and logging for individual users. If you are troubleshooting why a background process persists after logout, checking the status of the user manager often reveals more than the system-wide journal. For deeper insights into how variables interact with these units, you might want to review
Understanding Variable Usage in systemd Unit Files.
PAM Session Termination Sequence
The key to understanding shutdown behavior lies in the Pluggable Authentication Modules (PAM). When a user logs out or the system initiates a shutdown while the user is active, PAM executes the
session type modules in reverse order of their loading. The module
pam_systemd.so plays a pivotal role here. Upon session close, it sends a signal to the user's systemd instance, instructing it to begin shutting down its managed services.
This process is not instantaneous. PAM waits for the user manager to acknowledge that it has processed the stop requests. If a user unit has a long-running task without proper timeout configurations, PAM may hang until the kernel kills the process or the administrator intervenes. This interaction defines the boundary between "graceful logout" and "forced termination."
Shutdown Order and Timing
During a full system shutdown, the global shutdown target (
shutdown.target) is reached. At this point, systemd stops all remaining services. However, the timing of user unit termination relative to other system services can be nuanced. Historically, there was confusion about whether user units were stopped before or after network services went down.
Current versions of systemd generally ensure that the user manager is signaled to stop before the system completely powers off devices. However, if a user unit depends on network resources that are already being taken down, the user unit might fail to stop cleanly. To prevent race conditions where services shut down in an incorrect order, administrators can configure dependencies explicitly. As discussed in
Preserve Order of Closing Services While Shutting Down Linux, careful ordering prevents data corruption during abrupt power loss scenarios.
Configuring Graceful Shutdowns
To ensure your user units behave correctly during shutdown, you must define appropriate timeout values. In your
.service files under
~/.config/systemd/user/, use
TimeoutStopSec to specify how long systemd should wait for the process to exit gracefully. If the process does not exit within this timeframe, systemd sends a SIGKILL.
Additionally, consider using
ExecStopPost for cleanup tasks that do not require the main process to be alive. These commands run after the main process terminates but before the unit is marked as inactive. This is useful for removing temporary files or sending notification messages. Without these configurations, the default timeout might be too short for complex applications, leading to data loss.
Troubleshooting Persistent Processes
If you notice that processes continue to run after a user logs out, check the user journal using
journalctl --user -e. Look for errors related to socket activation or failed stop commands. Sometimes, the issue is not with the shutdown logic but with the application ignoring SIGTERM. You can test this manually by sending signals to the process ID found in the user scope.
Another common culprit is lingering sessions. By default, systemd destroys the user slice when the last session ends. If you enable lingering for a user, the user manager stays running even after logout, which changes the shutdown dynamics entirely. This is useful for system services that need to persist across reboots but can interfere with expected logout behaviors.
Frequently Asked Questions
Why do my user services keep running after I log out?
This usually happens because the user session is still considered active or lingering is enabled. Check if the user has lingering enabled with
loginctl show-user [username]. If you want services to stop immediately upon logout, ensure no lingering is set and that your services respond to SIGTERM correctly.
Can I prevent user units from stopping during a normal shutdown?
No, user units are tied to the user session. When the session ends or the system shuts down, the user manager receives a stop signal. You cannot easily bypass this without changing the fundamental architecture of how systemd manages user resources. Instead, focus on ensuring they stop cleanly and quickly.
What is the difference between Systemd User Units and System Units?
System units are managed by the root-owned system-wide systemd instance and typically start at boot regardless of user login. User units are managed by the per-user systemd instance and only exist when the user is logged in. They share the same syntax but operate in different namespaces and cgroup hierarchies.
How do I debug a stuck user shutdown?
Use
loginctl list-sessions to see active sessions and their states. Then, inspect the user journal with
journalctl --user -n 50 to find any errors reported by services failing to stop. You can also manually trigger a stop with
systemctl --user stop [service-name] to see immediate feedback.
Does enabling lingering affect shutdown performance?
Yes, enabling lingering keeps the user manager and its services running even after logout. This means that during a system shutdown, systemd must still stop these persistent services, which can add time to the shutdown process if the services are heavy or misconfigured. It effectively turns user services into system-like services that persist across reboots.