Stop wondering why systemd kills your long-running tasks after login

Technical Briefing | 10/4/2026

You finish a big data migration or a long-running compile, log out of your session, and come back an hour later to find your process is gone. It is not in the process list, it didn’t write its output, and the logs stop abruptly. This is the classic trap of KillUserProcesses in logind.conf, which treats your user sessions like disposable objects rather than environments for long-lived work.

The silent reaper in your user session

By default, modern systemd setups are configured to clean up everything a user starts once the last session closes. It makes sense for shared workstations to keep junk from piling up, but for a server where you expect your screen sessions or background jobs to persist, it is an absolute nightmare. When the last session ends, logind sends a SIGTERM to the whole process tree. You can fight this globally, but that is a sledgehammer approach when you only need to protect specific workflows.

systemd-run --user --scope --unit=persistent-worker bash -c 'sleep 1h; touch /tmp/done'

• Use systemd-run with –user to detach the process from the ephemeral session scope
• Check logind.conf if you actually need to disable this behavior system-wide
• Enable lingering for your user to keep the manager running even after logout

Running your task through systemd-run places it inside a service scope that systemd treats as independent of your terminal session. If you are doing this frequently, loginctl enable-linger [username] is the better fix, as it tells systemd to spawn a user manager at boot regardless of whether you have an active SSH connection. Just remember that long-running jobs are invisible until you explicitly manage them.