LFCA 35 🐧 Service States — Enabled vs Running
Every service on a systemd system has two independent states, and confusing them is the most common mistake in service management. A service can be running — the process is executing right now — and it can be enabled — it is configured to start when the system boots. These are separate questions with separate answers, and the commands that change them are different. A service can be running but not enabled, enabled but not running, both, or neither. The distinction matters because the two states answer different questions: the running state answers “is this capability available now?”, and the enabled state answers “will this capability be available after a reboot?”. Understanding the difference, and the four combinations, is what makes service management predictable. This chapter covers the two states, how to check them, how to change them, the common scenarios that arise from each combination, and the troubleshooting patterns for each.
Key point: systemctl is-active <unit> reports the running state — active or inactive. systemctl is-enabled <unit> reports the boot state — enabled, disabled, static, masked, or indirect. systemctl start and systemctl stop change the running state. systemctl enable and systemctl disable change the boot state. The two pairs are independent: enable does not start, and start does not enable. The --now flag combines them: systemctl enable --now <unit> enables and starts in one command, and systemctl disable --now <unit> disables and stops. systemctl status shows both states in one view.
The two questions
The running state and the enabled state answer two different questions, and the questions come up in different contexts.
“Is the service running now?” This is the question a user asks when a capability is not working. The web server is not responding, the SSH connection is refused, the cron job did not fire. The answer is in the running state, and the command is systemctl is-active.
“Will the service start after a reboot?” This is the question an administrator asks after configuring a service. The service was installed, configured, and started manually. Will it come back after the next reboot? The answer is in the enabled state, and the command is systemctl is-enabled.
Why the questions are separate. A service can be started manually for a test without being enabled for boot. A service can be enabled for boot without being started now. The two decisions are separate because they answer different needs: the immediate availability and the future availability.
Why the confusion is common. The words “start” and “enable” are close in meaning in everyday English, and the commands are both about making a service available. The distinction is technical: start is immediate, enable is at boot. The systemctl output uses different words for the two — “Active” for running, “Loaded” for enabled — which helps, but the initial confusion is common.
Why the distinction matters. A service that is running but not enabled disappears after a reboot, and the capability is lost without warning. A service that is enabled but not running is not available now, even though it will be after a reboot. Both combinations are legitimate in different situations, and knowing which one is in effect is the first step in diagnosing a service problem.
Why
systemctl statusshows both. The status output has two lines for the two states. The “Loaded” line shows the unit file path and the enable state —enabled,disabled,masked, orstatic. The “Active” line shows the running state —active (running),active (exited),inactive (dead), orfailed. Reading both lines is what gives the full picture, and the status command is the single command that shows them together.
The four combinations
The two binary states produce four combinations. Each is a legitimate configuration, and each has a use case.
Running and enabled. The service is active now and will start at boot. This is the normal state for a service that should always be available — sshd, NetworkManager, cron. The service was enabled and started, and both decisions are in effect.
Running but not enabled. The service is active now but will not start at boot. This happens when a service is started manually with systemctl start but never enabled, or when a service was enabled and then disabled without stopping. The service is available now but will disappear after a reboot.
Enabled but not running. The service is configured to start at boot but is not running now. This happens when a service is enabled but stopped, or when the service was enabled, the system booted, and the service failed. The service will attempt to start at the next boot, but it is not available now.
Neither running nor enabled. The service is stopped and will not start at boot. This is the state of a service that is installed but not in use — the package is present, the unit file exists, but the service is not part of the system’s active configuration.
| Active | Enabled | Meaning | Typical situation |
|---|---|---|---|
| Yes | Yes | Running, starts at boot | Normal operation |
| Yes | No | Running, does not start at boot | Manual start for testing |
| No | Yes | Stopped, starts at boot | Failed to start, or stopped manually |
| No | No | Stopped, does not start at boot | Installed but unused |
Why each combination is legitimate. The four combinations are not errors; they are four different configurations. A developer testing a service starts it without enabling it. An administrator disabling a service stops it and disables it. A service that is failing shows as enabled but not running, and the failure is the problem, not the state.
Why the combination is checked before acting. When a service is misbehaving, the first question is which of the four combinations is in effect. If the service is running but not enabled, the fix may be to enable it. If it is enabled but not running, the fix may be to start it or to investigate why it failed. The combination determines the action.
Why the combination is a common source of surprise. A service that is running but not enabled looks normal until the system reboots, and then the service is gone. The administrator who did not check the enabled state is surprised. The check is one command — systemctl is-enabled — and it prevents the surprise.
Checking the states
The commands that check the two states are systemctl is-active and systemctl is-enabled. Both return a single word and both use the exit status to signal the result.
systemctl is-active. Returns the active state.
$ systemctl is-active nginx
active
$ systemctl is-active cron
active
$ systemctl is-active some-stopped-service
inactiveThe possible values are active, inactive, failed, activating, and deactivating. The active value means the service is running. The inactive means it is stopped. The failed means it tried to start and exited with an error.
systemctl is-enabled. Returns the enable state.
$ systemctl is-enabled nginx
enabled
$ systemctl is-enabled some-disabled-service
disabled
$ systemctl is-enabled systemd-journald
staticThe possible values are enabled, disabled, static, masked, indirect, and generated. The enabled means the service starts at boot. The disabled means it does not. The static means the unit cannot be enabled directly — it is started as a dependency of another unit. The masked means it is completely disabled.
The exit status. Both commands exit 0 if the service is in the expected state and non-zero otherwise. is-active exits 0 for active and non-zero for the others. is-enabled exits 0 for enabled, enabled-runtime, static, indirect, and generated, and non-zero for disabled and masked. The status is what scripts use.
Why the exit status matters for scripts. A script that checks whether a service is running uses if systemctl is-active --quiet nginx; then .... The --quiet flag suppresses the output, and the exit status is the check. This is the standard pattern for a conditional in a script.
Why the output is a single word. The single-word output is easy to compare and easy to read. The alternative — parsing the status output — is fragile because the format changes between versions. The is-active and is-enabled commands are stable.
Why systemctl status is still useful. The is-active and is-enabled commands answer the specific question, and the status command shows the full picture. The status output includes the log lines, the process information, and the two states in a single view. For a quick check, the status command is often the fastest.
Why
list-units --state=failedis the diagnostic. The command lists the units that are in the failed state, which is the subset that needs attention. A service that failed to start is in this list, and the log entries are the next step. The command is the first thing to run after a boot that did not go as expected.
Changing the states
The commands that change the states are the pairs covered in the previous chapter. The key point here is that each pair changes one state and leaves the other alone.
Changing the running state. start, stop, restart, and reload change the running state. They do not change the enabled state.
sudo systemctl start nginx # active
sudo systemctl stop nginx # inactive
sudo systemctl restart nginx # active (new process)
sudo systemctl reload nginx # active (config re-read)A service that was enabled stays enabled after any of these commands. A service that was disabled stays disabled.
Changing the enabled state. enable, disable, mask, and unmask change the enabled state. They do not change the running state.
sudo systemctl enable nginx # enabled
sudo systemctl disable nginx # disabled
sudo systemctl mask nginx # masked
sudo systemctl unmask nginx # unmaskedA service that was running stays running after any of these commands. A service that was stopped stays stopped.
Why the independence is deliberate. The two decisions are separate because the needs are separate. An administrator may want to test a service without configuring it for boot, or configure a service for boot without starting it now. The separate commands give the separate decisions, and the --now flag combines them when both are wanted.
Why the commands do not interact. systemctl enable nginx does not start the service. systemctl start nginx does not enable it. The commands are orthogonal, and the state they change is the one named in the command. This is the model, and it is what makes the commands predictable.
Why the --now flag exists. The combination enable --now and disable --now is common enough that the flag is the convenience. The flag is not a different behavior; it is the two commands in one. The result is the same as running the two commands separately.
Common scenarios
The four combinations produce recognizable scenarios, and each has a pattern for the fix.
The service was started manually and never enabled. The service is running but not enabled. The administrator started it with systemctl start and intended to enable it but did not. The fix is systemctl enable nginx, which adds the boot configuration without affecting the running service. The service continues running and now starts at boot.
The service was enabled and then stopped. The service is enabled but not running. The administrator stopped it with systemctl stop and did not disable it. The service will start at the next boot. The fix depends on the intent: if the service should be running, start it; if it should not start at boot, disable it.
The service failed to start. The service is enabled but not running, and the reason is a failure rather than a manual stop. The systemctl status shows failed in the Active line, and the log shows the reason. The fix is to diagnose the failure with journalctl -u nginx -xe and correct the cause.
The service is installed but not in use. The service is neither running nor enabled. The package is present, the unit file exists, but the service is not part of the active configuration. This is the state of a service that has been installed but not configured, or that was disabled and stopped.
The service is masked. The service is masked, which is a stronger form of disabled. The is-enabled returns masked, and the service cannot be started even as a dependency. This is used to prevent a service from running at all, and it is reverted with unmask.
The service is static. The service is static, which means it cannot be enabled directly. The service is started as a dependency of another unit, and the enable command has no effect. The is-enabled returns static, and the service is managed through the unit that requires it.
The service is running from a manual start in a different shell. The service is active but the jobs command in another shell does not show it. This is the difference between a service and a shell job. The service is managed by systemd, and the systemctl commands are the interface. The shell job control is separate.
Why the scenarios are the diagnostic. Each scenario has a different fix, and the fix depends on the combination. The systemctl status output and the two state commands are how the combination is determined, and the fix follows from the combination. The pattern is: check the states, determine the combination, apply the fix.
Troubleshooting
The two states are the starting point for most service problems, and the troubleshooting follows a predictable path.
The service is not running and should be. The first question is whether it is enabled. If it is enabled and not running, it failed to start, and the log is the next step. If it is not enabled, the fix may be to enable it.
The service is running but not available. The running state is active, but the service is not responding. This is a different problem — the process is alive but not working. The diagnosis involves the listening socket, the internal state, and the resource usage. The two-state check is not enough.
The service disappeared after a reboot. The service was running but not enabled, and the reboot stopped it. The fix is to enable it. The check is systemctl is-enabled, and the fix is systemctl enable.
The service started at boot but should not. The service is enabled but should not be. The fix is systemctl disable, which removes the boot configuration. The running service continues until it is stopped or the system shuts down.
The service is masked and cannot be started. The is-enabled returns masked. The fix is systemctl unmask, which removes the mask. The service can then be started or enabled.
The service is static and enable has no effect. The is-enabled returns static. The unit cannot be enabled directly because it is started as a dependency. The management is through the requiring unit, not the static one.
Why the troubleshooting is a sequence. The sequence is: check the active state, check the enabled state, determine the combination, check the log if there is a failure, apply the fix. The sequence is the same for every service problem, and the two states are the first two steps.
Why the log is the final arbiter. If the service is failing to start, the log has the reason. The two states tell you that the service is not running and is enabled, which means it tried to start and failed. The log tells you why. The combination narrows the problem, and the log gives the cause.
Why the two-state model is the mental model for services. Every service question reduces to the two states and the actions on them. “Why is this service not available?” is “is it running?” and “why not?” “Will this service survive a reboot?” is “is it enabled?” The two questions are the model, and the
systemctlcommands are the operations on the model.
Complete Example Session
# ============================================
# PART 1: CHECK BOTH STATES
# ============================================
systemctl is-active nginx
# active
systemctl is-enabled nginx
# enabled
# Running and enabled — the normal state.
# ============================================
# PART 2: RUNNING BUT NOT ENABLED
# ============================================
sudo systemctl start myapp
systemctl is-active myapp
# active
systemctl is-enabled myapp
# disabled
# The service is running but will not start at boot.
# Fix: enable it.
sudo systemctl enable myapp
systemctl is-enabled myapp
# enabled
# ============================================
# PART 3: ENABLED BUT NOT RUNNING
# ============================================
sudo systemctl stop nginx
systemctl is-active nginx
# inactive
systemctl is-enabled nginx
# enabled
# The service will start at the next boot.
# Fix depends on intent: start it, or disable it.
sudo systemctl start nginx
# or
sudo systemctl disable nginx
# ============================================
# PART 4: FAILED TO START
# ============================================
systemctl is-active nginx
# failed
systemctl is-enabled nginx
# enabled
# The service tried to start and failed.
# The log has the reason.
journalctl -u nginx -xe
# nginx: [emerg] bind() to 0.0.0.0:80 failed
# ============================================
# PART 5: NEITHER
# ============================================
systemctl is-active apache2
# inactive
systemctl is-enabled apache2
# disabled
# Installed but not in use.
# ============================================
# PART 6: THE FOUR COMBINATIONS
# ============================================
# For each service, check both:
for svc in nginx ssh cron docker; do
printf "%-12s active=%-8s enabled=%s\n" \
"$svc" \
"$(systemctl is-active $svc)" \
"$(systemctl is-enabled $svc)"
done
# nginx active=active enabled=enabled
# ssh active=active enabled=enabled
# cron active=active enabled=enabled
# docker active=inactive enabled=disabled
# ============================================
# PART 7: THE ENABLE --NOW FORM
# ============================================
sudo systemctl enable --now nginx
# Enables and starts in one command.
sudo systemctl disable --now nginx
# Disables and stops in one command.
# ============================================
# PART 8: MASKED
# ============================================
sudo systemctl mask nginx
systemctl is-enabled nginx
# masked
sudo systemctl start nginx
# Failed to start nginx.service: Unit nginx.service is masked.
sudo systemctl unmask nginx
systemctl is-enabled nginx
# disabled
# ============================================
# PART 9: STATIC
# ============================================
systemctl is-enabled systemd-journald
# static
# Cannot be enabled directly.
# Started as a dependency of another unit.
# ============================================
# PART 10: STATUS SHOWS BOTH
# ============================================
systemctl status nginx
# ● nginx.service - A high performance web server
# Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
# ▲
# └── the enabled state
# Active: active (running) since Mon 2026-03-15 10:00:00 UTC
# ▲
# └── the running state
# ============================================
# PART 11: THE DIAGNOSTIC LOOP
# ============================================
# 1. Is it running?
systemctl is-active nginx
# 2. Is it enabled?
systemctl is-enabled nginx
# 3. If enabled and not running, why?
journalctl -u nginx -xe
# 4. Apply the fix.
# ============================================
# PART 12: WHAT NOT TO DO
# ============================================
# Don't assume start means enable
sudo systemctl start nginx # does not start at boot
# Don't assume enable means start
sudo systemctl enable nginx # does not start now
# Don't forget to check both states
# A service can be in any of four combinations.
# Don't ignore the failed state
# The log has the reason.
# Don't mask without understanding
# Mask prevents any start.The twelve parts cover checking the states, the four combinations, the fix for each, enable --now, mask and static, the status output, the diagnostic loop, and the anti-patterns.
Quick Reference
State Commands
| Command | Reports |
|---|---|
systemctl is-active unit | Running state |
systemctl is-enabled unit | Boot state |
systemctl status unit | Both states + log |
systemctl list-units --state=failed | Failed units |
State Values
is-active | Meaning |
|---|---|
active | Running |
inactive | Stopped |
failed | Exited with error |
activating | Starting |
deactivating | Stopping |
is-enabled | Meaning |
|---|---|
enabled | Starts at boot |
disabled | Does not start at boot |
static | Cannot be enabled directly |
masked | Cannot be started at all |
indirect | Enabled through another unit |
generated | Generated by systemd |
The Four Combinations
| Active | Enabled | Meaning |
|---|---|---|
| Yes | Yes | Normal, running and persistent |
| Yes | No | Running but temporary |
| No | Yes | Stopped but will start at boot |
| No | No | Not in use |
Change Commands
| State | Change | Command |
|---|---|---|
| Running | Start | systemctl start |
| Running | Stop | systemctl stop |
| Boot | Enable | systemctl enable |
| Boot | Disable | systemctl disable |
| Both | Enable and start | systemctl enable --now |
| Both | Disable and stop | systemctl disable --now |
Exit Status in Scripts
| Check | Condition |
|---|---|
systemctl is-active --quiet unit | 0 if active |
systemctl is-enabled --quiet unit | 0 if enabled |
systemctl is-failed unit | 0 if failed |
Best Practices
✅ Do This:
# Check both states
systemctl is-active nginx && systemctl is-enabled nginx # ✅
# Use enable --now for both decisions
sudo systemctl enable --now nginx # ✅
# Read the status for both states in one view
systemctl status nginx # ✅
# Check the log when a service is enabled but not running
journalctl -u nginx -xe # ✅
# Use --quiet in scripts
if systemctl is-active --quiet nginx; then echo "running"; fi # ✅
# Check the failed list after a boot
systemctl list-units --state=failed # ✅
# Unmask before starting a masked service
sudo systemctl unmask nginx # ✅❌ Don’t Do This:
# Don't assume start enables
sudo systemctl start nginx # not enabled for boot # ⚠️
# Don't assume enable starts
sudo systemctl enable nginx # not running now # ⚠️
# Don't check only one state
# The service can be in any of four combinations # ⚠️
# Don't ignore the failed state
# It means the service tried and failed # ⚠️
# Don't mask without understanding
# Masking prevents any start, even as a dependency # ⚠️
# Don't use enable on a static unit
# Static units cannot be enabled directly # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
| Start assumed to enable | Service gone after reboot | enable --now |
| Enable assumed to start | Service not running now | start or enable --now |
| Only one state checked | Wrong diagnosis | Check both |
| Failed state ignored | Cause unknown | journalctl -u |
| Mask confused with disable | Cannot start | unmask |
| Static unit enabled | No effect | Manage the requiring unit |
| Exit status ignored | Script logic wrong | Check --quiet |
| Service disappeared after reboot | Not enabled | systemctl enable |
Real-World Examples
1. Check active
systemctl is-active nginx2. Check enabled
systemctl is-enabled nginx3. Both in one view
systemctl status nginx4. Enable and start
sudo systemctl enable --now nginx5. Disable and stop
sudo systemctl disable --now nginx6. Find failed units
systemctl list-units --state=failed7. Diagnose a failure
systemctl is-active nginx && journalctl -u nginx -xe8. Check in a script
if systemctl is-active --quiet nginx; then ...; fi9. Unmask
sudo systemctl unmask nginx10. The four-combination loop
for svc in nginx ssh cron; do
echo "$svc: $(systemctl is-active $svc) / $(systemctl is-enabled $svc)"
doneVisual: The Two States
┌──────────────────────────────────────────────────────────┐
│ RUNNING STATE (active / inactive) │
│ The process is executing now. │
│ Changed by: start, stop, restart, reload │
│ Checked by: is-active, status │
│ │
├──────────────────────────────────────────────────────────┤
│ ENABLED STATE (enabled / disabled) │
│ The service is configured to start at boot. │
│ Changed by: enable, disable, mask, unmask │
│ Checked by: is-enabled, status │
│ │
├──────────────────────────────────────────────────────────┤
│ THE TWO ARE INDEPENDENT │
│ │
│ start ≠ enable │
│ stop ≠ disable │
│ enable --now = both │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Four Combinations
┌──────────────────────────────────────────────────────────┐
│ ┌─────────────┬─────────────┬──────────────────────┐ │
│ │ ACTIVE │ ENABLED │ MEANING │ │
│ ├─────────────┼─────────────┼──────────────────────┤ │
│ │ Yes │ Yes │ Normal operation │ │
│ │ Yes │ No │ Running, temporary │ │
│ │ No │ Yes │ Stopped, will boot │ │
│ │ No │ No │ Installed, unused │ │
│ └─────────────┴─────────────┴──────────────────────┘ │
│ │
│ The first is the target for a service that should │
│ always be available. │
│ │
│ The second is a manual start for a test. │
│ │
│ The third is a stopped service, or a failed one. │
│ │
│ The fourth is a service not in use. │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Diagnostic Loop
┌──────────────────────────────────────────────────────────┐
│ 1. systemctl is-active nginx │
│ │ │
│ ├── active ──► the service is running │
│ │ │ │
│ │ └── is it enabled? │
│ │ systemctl is-enabled nginx │
│ │ │
│ └── inactive / failed │
│ │ │
│ ├── is it enabled? │
│ │ │ │
│ │ ├── yes ──► it failed to start │
│ │ │ │ │
│ │ │ └── journalctl -u nginx -xe │
│ │ │ │
│ │ └── no ──► it was stopped or not │
│ │ enabled │
│ │ │
│ └── apply the fix │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Status Output
┌──────────────────────────────────────────────────────────┐
│ systemctl status nginx │
│ │
│ ● nginx.service - A high performance web server │
│ Loaded: loaded (/lib/systemd/system/nginx.service; │
│ enabled; preset: enabled) │
│ ▲ │
│ └── the ENABLED state │
│ │
│ Active: active (running) since ... │
│ ▲ │
│ └── the RUNNING state │
│ │
│ Main PID: 1235 (nginx) │
│ Tasks: 3 │
│ Memory: 12.3M │
│ │
│ Both states in one view. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Fix by Combination
┌──────────────────────────────────────────────────────────┐
│ Running, not enabled │
│ Fix: sudo systemctl enable nginx │
│ The service continues running and now starts at boot. │
│ │
├──────────────────────────────────────────────────────────┤
│ Enabled, not running (stopped manually) │
│ Fix A: sudo systemctl start nginx (make it running) │
│ Fix B: sudo systemctl disable nginx (do not boot it) │
│ │
├──────────────────────────────────────────────────────────┤
│ Enabled, not running (failed) │
│ Fix: journalctl -u nginx -xe, correct the cause, then │
│ sudo systemctl start nginx │
│ │
├──────────────────────────────────────────────────────────┤
│ Not running, not enabled │
│ Fix: sudo systemctl enable --now nginx │
│ If the service should be in use. │
│ │
└──────────────────────────────────────────────────────────┘Summary
| State | Command | Values |
|---|---|---|
| Running | systemctl is-active | active, inactive, failed |
| Enabled | systemctl is-enabled | enabled, disabled, static, masked |
| Both | systemctl status | Both in one view |
| Combination | Meaning |
|---|---|
| Active + Enabled | Normal, persistent |
| Active + Disabled | Running but temporary |
| Inactive + Enabled | Stopped but will start at boot |
| Inactive + Disabled | Not in use |
| Action | Command |
|---|---|
| Start now | systemctl start |
| Enable for boot | systemctl enable |
| Both | systemctl enable --now |
| Stop now | systemctl stop |
| Disable for boot | systemctl disable |
| Both | systemctl disable --now |
Key takeaways:
- Running and enabled are two independent states — the running state answers “is it available now?”, the enabled state answers “will it start at boot?”
systemctl is-activereports the running state —active,inactive,failed,activating,deactivatingsystemctl is-enabledreports the boot state —enabled,disabled,static,masked,indirect,generatedstartchanges the running state andenablechanges the boot state — the commands are orthogonal, and neither implies the other- The four combinations are all legitimate — running and enabled, running but not enabled, enabled but not running, neither — and each has a use case
- The
--nowflag combines the two decisions —enable --nowanddisable --noware the convenience forms - A service that is enabled but not running has either been stopped or failed — the
failedactive state indicates a failure, and the log has the reason systemctl statusshows both states in one view — the “Loaded” line is the enabled state, the “Active” line is the running state- The diagnostic loop is check active, check enabled, check the log, apply the fix — the same sequence for every service problem
- The exit status of
is-activeandis-enabledis the script-friendly check —--quietsuppresses the output and the exit status is the condition
Remember: Every service question reduces to two: is it running, and will it start at boot? The two states are independent, the commands that change them are separate, and the four combinations are the model. Check both states, determine the combination, and the fix follows. A service that is running but not enabled disappears at the next reboot; a service that is enabled but not running has either been stopped or failed. Knowing which is which is what makes service management predictable.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!