You spend half the morning tuning a long-running data transformation script, you kick it off, disconnect your SSH session, and head to lunch. You come back, re-attach, and find out the process died the moment your session ended. We have all been there. Most tutorials tell you to use screen or tmux, but if you are already managing a production server, you should just let systemd-run handle the persistence for you.

Why your shell is trying to kill your work

When you log out, your shell sends a SIGHUP to its process group. Even if you use nohup, you are still bound to the lifecycle of that session. If the parent scope gets cleaned up by a PAM module or a restrictive login configuration, your process is gone. systemd-run detaches the task from your shell session entirely by placing it into its own transient transient service unit.

systemd-run --user --scope --unit=my-long-job python3 heavy_script.py

• The –user flag keeps it under your control without requiring root access
• The –scope flag keeps the process alive even after the command exits
• The –unit flag lets you name it so you can actually find it later with systemctl

Verifying the handoff

Once you run that, check systemctl –user status my-long-job. You will see it running as a legitimate service rather than a backgrounded shell job. You can log out, go home, sleep for eight hours, and it will still be there doing its thing. If you find yourself doing this for the same job every week, stop using manual commands and just drop a proper unit file in ~/.config/systemd/user/. That way, you have a declarative record of what is actually running on your box instead of relying on your shell history.