Task guide Keep Long-Running Work Alive After Disconnect
Use this when a command or script must outlive your current terminal or remote login.
A lot of accidental process loss happens because people background a job and assume it will survive disconnects, reboots, or policy changes.
Processes 15 min both
Safe first move Know whether the work is interactive, reconnectable, or service-like. Do not confuse backgrounding a command with making it persistent.
Use this when Use this when a command or script must outlive your current terminal or remote login.
Goal
Pick the right running model so the work survives in the way you actually need.
Safe sequence
- Decide whether you only need the prompt back or real persistence.
- Decide whether you must reconnect to the session later.
- Decide whether the OS should supervise restart behavior.
- Choose the lightest model that still meets the need.
- Verify that the model matches disconnect or restart expectations.
Good defaults
- shell job: short or watched work in the same session
- persistent session: reconnectable long work
- supervised service: long-lived workload that should be managed by the OS
Move on when
- You can explain what survives the end of the current session.
- You know whether the work needs supervision or only persistence.
- You can justify the chosen model in one sentence.
Before you start - Know whether the work is interactive, reconnectable, or service-like.
- Decide whether the job should survive disconnects, reboots, or both.
- Prefer a persistent session or service only when the workload really needs it.
Verify with - You can explain what keeps the work alive.
- You know whether the design survives disconnects or only keeps the prompt free.
- You can name the next safer option if the current model is too weak.
Avoid these mistakes - Do not confuse backgrounding a command with making it persistent.
- Do not turn one-off work into a service by habit.
- Do not leave critical work attached to one fragile shell session.
Move on when - You can classify a workload by needed persistence.
- You can explain the difference between reconnectability and supervision.
- You can choose the lightest safe model for one real example.
Reflect before you leave - What makes a workload deserve service supervision instead of a shell session?
- What would have been misleading about backgrounding this job and walking away?
Review this task again in about 1, 7, 21 days.
Learn deeply M21 - Background and Foreground Understand how foreground work, background jobs, and persistent sessions differ so long-running commands do not surprise you or die unexpectedly.
M21A - Jobs, Sessions, and Services Understand when a background job is enough, when a persistent session is better, and when the operating system should supervise the work as a service.
M22A - Services, Supervision, and Restart Loops Connect services to process supervision so start failures, restart loops, and service health are easier to diagnose before you restart anything.