You need a backup script to keep running overnight after you disconnect from SSH. A plain background job may not survive the disconnect, but a tmux session or a supervised service can.
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.
Processes
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.
30 min INTERMEDIATE BOTH Field-verified
Before this lesson
What you should learn
- 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.
Visual model
Concept to practice path
Each lesson is meant to move from an idea, to an example, to a safe practice step.
Open the full visualWhy This Matters
Many process mistakes are really context mistakes.
People often know how to start work, but not how the operating system will treat that work over time.
That leads to common surprises:
- a background task disappears when the terminal closes
- a remote command dies after disconnect
- a service keeps restarting because it is meant to be supervised
- someone treats a service like a one-off shell command
Real scenario
One practical question
The important question is not just 'is it running?' It is 'what is supposed to keep it alive?'
1. A Job Lives Close to Your Shell
A foreground or background job is still closely tied to the shell session that started it.
That makes job control useful for:
- short or medium tasks
- interactive command work
- situations where you are staying in the same session
It is weaker for:
- dropped remote sessions
- unattended work
- workloads that should restart automatically
2. A Persistent Session Extends the Terminal Model
Tools such as tmux, screen, or a separate detached console are useful when the terminal should stay resumable.
This is still not the same thing as a managed service.
A persistent session helps you reconnect to the work. A service manager helps the operating system supervise the work.
3. A Service Is a Supervised Promise
A service is meant to be:
- started in a known way
- tracked by the operating system
- checked for state
- optionally restarted
- connected to boot behavior and logging
Practical Rule
If the work should survive user logouts, be monitored, or restart automatically, stop thinking like a shell job and start thinking like a service or scheduled workload.
4. The Safer Choice Depends on the Job
Decision guide
Pick the right running model
Action
Choose this when
Do not start here when
What to Do Next
The next lesson moves into performance diagnosis, where these running contexts start to matter in real slow-system situations.
After that, the service-supervision lesson will make restart loops and service state easier to reason about.
Learning loop
Recall it, check it, then practice it.
Do this before moving on. It turns reading into memory and safer action.
- Why is a background job not automatically a persistent workload?
- When should a service manager replace a shell-based workflow?
- Explain the difference between a background job, a persistent session, and a service without notes.
- Choose the safer running model for one real scenario.
Review again after 1, 3, 7 days.
What to do next
Best next step PracticeUse the matching lab or keep building skill in practice.