You spend half an hour tuning a simulation or a heavy build process, hit enter, and close your SSH session to grab a coffee. When you come back, the process is dead. It isn’t a crash, it’s not a OOM killer incident, and there isn’t even a core dump. It is systemd doing exactly what it was told, which is cleaning up your user session’s processes the second your last shell disconnects.

Why your background tasks vanish

This bit me in prod years ago when a migration script I kicked off manually died without a trace. The culprit is KillUserProcesses=yes in logind.conf. It defaults to enabled on many modern distributions to prevent resource leaks, but it doesn’t care if you have critical work running in a screen or tmux session. It effectively sends SIGTERM to everything in your control group when the session ends.

loginctl enable-linger $USER

• Enabling linger allows systemd to maintain a user-specific manager even when no session is active
• It prevents logind from sending signals to your detached tmux or screen processes
• This is a per-user setting that persists across reboots, so keep track of which accounts have it enabled

Don’t just blindly toggle this for every user on the box. It is a convenience feature, but if you have a multi-tenant environment, you might prefer just wrapping your one-off scripts in a systemd transient unit instead. That way, you get the lifetime management without modifying global session behavior. The next time you find yourself wondering why your jobs stop when you leave, check your logind status before digging into code logs.