LFCA 34 🐧 Managing Services with systemctl
The previous chapter explained what system services are and how systemd defines them. This chapter is about the command that controls them: systemctl. It is the single interface to the init system — starting, stopping, restarting, reloading, enabling, disabling, and inspecting every service on the machine. A service that is not running is started with systemctl start, a service that should start at boot is enabled with systemctl enable, a service that is misbehaving is inspected with systemctl status, and the log is read with journalctl. The command is large, but the subset that matters in daily work is small, and the concepts behind it — active vs enabled, start vs restart, reload vs restart — are what make the commands predictable. This chapter covers the full set of commands, the distinction between runtime state and boot state, the patterns for safe service management, and the recovery from the common failures.
Key point: systemctl operates on units — services, sockets, timers, mounts, targets, and more. A unit has two independent states: active (running now) and enabled (starts at boot). systemctl start changes the active state; systemctl enable changes the enabled state. The two are separate, and a service can be active but not enabled, enabled but not active, both, or neither. systemctl restart stops and starts; systemctl reload re-reads the configuration without stopping. systemctl status shows the current state, the recent log entries, and the process information. systemctl daemon-reload is required after editing a unit file. The journalctl -u command reads the service’s log.
The systemctl command model
systemctl takes a subcommand and a unit name. The subcommand is the action, and the unit name is the target. The unit name is usually the service name with a .service suffix, but the suffix can be omitted for services.
systemctl status ssh
systemctl start ssh
systemctl stop ssh
systemctl restart ssh
systemctl reload ssh
systemctl enable ssh
systemctl disable sshThe same pattern applies to every unit type: systemctl start nginx, systemctl status cron, systemctl enable docker. The .service suffix is implied for services, and the other types have their own suffixes (.socket, .timer, .mount, .target).
Why the unit name is the identifier. A unit is identified by its name, and the name is the filename of the unit file. ssh.service is the unit ssh, and the file is /lib/systemd/system/ssh.service. The name is how systemctl finds the unit.
Why the suffix is usually omitted for services. The .service suffix is the default for systemctl, so systemctl start ssh and systemctl start ssh.service are the same. The suffix is required for other unit types — systemctl start ssh.socket for the socket unit, systemctl start logrotate.timer for the timer unit.
Why the command is a single tool. Traditional SysV systems had service for runtime actions and chkconfig or update-rc.d for boot state. systemctl combines both, and the enable and disable subcommands replace the separate tools. The consolidation is one of the reasons systemd is simpler to use.
Why the command requires privileges for most actions. Starting, stopping, and enabling a service changes the system state, so systemctl requires root for these actions. The query actions — status, list-units, is-active — are readable by any user. The sudo prefix is required for the modifying actions.
Why the --user flag manages user services. A user can manage their own services with systemctl --user, which operates on the user’s systemd instance. The user services are defined under ~/.config/systemd/user/ and run with the user’s privileges. This is used for per-user daemons and is separate from the system services.
Why the unit name must match exactly. A typo in the unit name produces “Unit not found,” and the fix is to check the exact name with
systemctl list-units. The names are case-sensitive, and the suffix must be correct for non-service units. Thesystemctl list-unit-filescommand shows every unit the system knows, and it is the reference for the names.
Starting, stopping, and restarting
The lifecycle commands change the active state of a service.
systemctl start. Starts a service that is not running. The command returns when the service has reached the active state, or reports an error if it fails.
sudo systemctl start nginxIf the service is already running, the command is a no-op. If it fails to start, the error is printed and the exit status is non-zero.
systemctl stop. Stops a running service. The command runs the ExecStop directive (or sends SIGTERM to the main process) and waits for the service to reach the inactive state.
sudo systemctl stop nginxIf the service is already stopped, the command is a no-op. If it fails to stop, the error is printed.
systemctl restart. Stops and then starts the service. This is the command for applying a configuration change that the service cannot reload.
sudo systemctl restart nginxThe service is stopped (with ExecStop) and started (with ExecStart). The downtime is the time it takes for the two steps, which is usually short but not zero.
systemctl reload. Re-reads the configuration without stopping the service. The ExecReload directive defines the command.
sudo systemctl reload nginxThe service continues running and applies the new configuration. This is preferred over restart when the service supports it, because there is no downtime.
Why reload is preferred when available. A restart takes the service down for the duration of the stop and start, which means a brief interruption for the clients. A reload keeps the service running and applies the configuration in place, which means no interruption. The services that support reload are the ones that can re-read their configuration at runtime, which is most network services.
Why restart is sometimes necessary. Some configuration changes cannot be applied by reload — a change to the listening port, a change to the user the service runs as, a change to a library the service loads. For these, a restart is required, and the interruption is unavoidable.
Why systemctl try-restart exists. The try-restart subcommand restarts a service only if it is already running. If it is stopped, the command does nothing. This is useful in scripts where the service should be restarted if present but not started if absent.
Why systemctl reload-or-restart exists. The reload-or-restart subcommand reloads if the service supports it and restarts otherwise. It is the convenience command for “apply the configuration however the service prefers.”
Why the commands are synchronous. The systemctl command waits for the service to reach the target state before returning. The wait is the confirmation that the action succeeded or failed, and the exit status is the result. The scripts that call systemctl can rely on the status.
Enabling and disabling
The enable and disable commands change the boot state, not the runtime state. They are independent of start and stop.
systemctl enable. Configures the service to start at boot. The command creates the symlinks declared in the unit’s [Install] section.
sudo systemctl enable nginxThe service is not started by this command. It is configured to start at the next boot. If the service is currently running, it continues running; if it is not, it stays stopped.
systemctl disable. Removes the boot configuration. The service is no longer started at boot.
sudo systemctl disable nginxThe service is not stopped by this command. It continues running until it is stopped or the system shuts down. The next boot does not start it.
The two states are independent. A service can be:
| Active | Enabled | Meaning |
|---|---|---|
| Yes | Yes | Running now, starts at boot |
| Yes | No | Running now, does not start at boot |
| No | Yes | Not running, starts at boot |
| No | No | Not running, does not start at boot |
The systemctl status output shows both states. The enabled or disabled in the “Loaded” line and the active or inactive in the “Active” line are the two states.
Why the independence is important. A service can be enabled but stopped — it will start at the next boot. A service can be active but disabled — it is running now but was started manually and will not start at the next boot. The two commands are separate because the two states are separate, and the administrator must consider both.
systemctl enable --now. The --now flag combines enable and start.
sudo systemctl enable --now nginxThe service is enabled and started in one command. The disable --now combines disable and stop. This is the convenience form, and it is the one to use when both actions are wanted.
systemctl is-enabled. Checks the enable state without changing it.
systemctl is-enabled nginx
# enabled
# disabled
# staticThe static value means the unit cannot be enabled directly; it is started as a dependency of another unit. The masked value means the unit is disabled in a way that prevents it from being started.
systemctl mask. The mask command disables a unit completely. It creates a symlink to /dev/null, which makes the unit impossible to start, even as a dependency.
sudo systemctl mask nginx
sudo systemctl unmask nginxMasking is stronger than disabling. A disabled service can still be started manually or by a dependency; a masked service cannot. This is used to prevent a service from being started at all, which is useful when the service should never run on the system.
Why enable does not start. The separation is deliberate. The administrator may want to configure a service to start at boot without starting it now, or start a service now without configuring it for boot. The two commands give the two decisions separately, and the --now flag combines them when both are wanted.
Querying the state
The query commands read the current state without changing it.
systemctl status. Shows the state of a unit, the recent log entries, and the process information.
systemctl status nginx
# ● nginx.service - A high performance web server
# Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
# Active: active (running) since Mon 2026-03-15 10:00:00 UTC; 2h ago
# Docs: man:nginx(8)
# Process: 1234 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
# Main PID: 1235 (nginx)
# Tasks: 3 (limit: 12345)
# Memory: 12.3M
# CPU: 234ms
# CGroup: /system.slice/nginx.service
# ├─1235 "nginx: master process /usr/sbin/nginx"
# ├─1236 "nginx: worker process"
# └─1237 "nginx: worker process"The output includes the unit description, the loaded state and the enable status, the active state and the time, the process tree, and the last few log lines. It is the first command to run when diagnosing a service.
systemctl is-active. Returns the active state as a single word.
systemctl is-active nginx
# active
# inactive
# failedThe command is useful in scripts, where the exit status is the check. is-active exits 0 if the service is active and non-zero otherwise.
systemctl is-enabled. Returns the enable state, as covered above.
systemctl list-units. Lists the units that are currently loaded.
systemctl list-units --type=service
systemctl list-units --state=failed
systemctl list-units --allThe --type filter limits the list to a unit type. The --state filter limits it to a state. The --all flag includes inactive units, which are hidden by default.
systemctl list-unit-files. Lists the unit files installed on the system, with their enable state. This is the reference for which services exist and which are enabled.
systemctl list-unit-files --type=service
# UNIT FILE STATE
# ssh.service enabled
# nginx.service disabled
# cron.service enabled
# ...systemctl show. Shows all the properties of a unit in key-value form. The output is large and is intended for scripting.
systemctl show nginx
systemctl show nginx -p ActiveState -p SubStateThe -p flag limits the output to specific properties. The ActiveState and SubState are the two properties that describe the active state.
systemctl cat. Shows the unit file and any overrides.
systemctl cat nginxThe command prints the package’s unit file and any files in the override directories, in the order they are applied. It is the way to see what systemd actually reads for the unit.
Why the query commands are readable by any user. The state of the services is not sensitive, and the query commands do not change anything. Any user can run systemctl status, and the information is available without sudo. The modifying commands require root.
Why the --no-pager flag is useful in scripts. The systemctl output goes through a pager by default, which is fine interactively and wrong in scripts. The --no-pager flag disables the pager, and the output goes directly to the terminal or the pipe.
The journal
The journalctl command reads the system journal, which collects the output of every service. The -u flag limits the output to a single unit.
journalctl -u nginx
journalctl -u nginx -n 20
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx --since today
journalctl -u nginx -p errThe -n flag shows the last N lines, the -f flag follows the log, the --since flag limits the time range, and the -p flag limits the priority. The combination is the way to read a service’s log.
Why the journal is better than a log file. The journal collects the output of every service in one place, with timestamps and metadata. The journalctl command queries it with filters, which is easier than grepping through multiple files. The journal persists across reboots if the persistent storage is enabled, and the logs are consistent.
Why the -u flag is the first filter. The journal contains the output of every service, so the -u flag limits it to one. The flag can be repeated to show several units. The -u flag is the standard way to read a service’s log.
Why the -f flag is useful. The -f flag follows the log, like tail -f. It shows the new entries as they arrive, which is the way to watch a service in real time. The combination journalctl -u nginx -f is the standard command for watching a service.
Why the priority filter matters. The -p err flag shows only the entries at the error priority or higher. The journal has the standard syslog priorities — emerg, alert, crit, err, warning, notice, info, debug — and the filter is the way to find the important entries in a large log.
Why the time filters matter. The --since and --until flags limit the range. The --since "1 hour ago" form is useful for a recent failure, and the --since today form is useful for a daily review. The time filters are the way to narrow a large journal.
Why the journal can be read by any user for their own services. The journal’s access control lets a user read the entries for their own services without root. The system services require root or membership in the systemd-journal group. This is the privilege model for the log.
Why
journalctl -xeis the diagnostic command. The-xflag adds explanatory text to the entries, and the-eflag jumps to the end. The combination shows the most recent entries with explanations, which is the fastest way to see what failed. The command is the first thing to run after a service fails.
Editing units and the daemon-reload
A unit file is edited with systemctl edit, which creates an override rather than modifying the package’s file. After any change to a unit file, systemctl daemon-reload must be run to make systemd re-read the units.
systemctl edit. Creates or edits an override file in /etc/systemd/system/<unit>.d/override.conf.
sudo systemctl edit nginxThe editor opens with an empty override file. The directives in the override are merged with the package’s unit file, with the override taking precedence for the directives it specifies. The original file is not modified.
Why the override is the right approach. The package’s unit file is replaced when the package is upgraded, so any direct edit is lost. The override is in /etc, which the package does not touch, so the customization survives the upgrade. This is the standard way to customize a packaged unit.
systemctl daemon-reload. Re-reads all the unit files and rebuilds the dependency graph.
sudo systemctl daemon-reloadThe command is required after any change to a unit file, whether the change was made with systemctl edit or by hand. Without it, systemd continues to use the old definitions.
Why the reload is required. systemd caches the unit definitions in memory. The cache is not invalidated by a file change, because systemd does not watch the files. The daemon-reload is the explicit signal to re-read, and it is a required step in the edit cycle.
Why daemon-reload is not the same as reload. The systemctl reload nginx reloads the service’s configuration. The systemctl daemon-reload reloads systemd’s own unit definitions. The two are different, and the daemon-reload is the one after editing a unit file.
The edit cycle. The full cycle for changing a service’s unit is:
sudo systemctl edit nginx # edit the override
sudo systemctl daemon-reload # re-read the units
sudo systemctl restart nginx # apply the changeThe daemon-reload is between the edit and the restart. Without it, the restart uses the old definition.
Why systemctl edit --full is different. The --full flag edits the entire unit file rather than an override. The result is a copy of the unit in /etc/systemd/system/, which overrides the package’s file completely. This is used when the unit is being replaced rather than customized, and it has the disadvantage that the package’s updates to the unit are not applied.
Complete Example Session
# ============================================
# PART 1: CHECK THE STATUS
# ============================================
systemctl status nginx
# ● nginx.service - A high performance web server
# Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
# Active: active (running) since Mon 2026-03-15 10:00:00 UTC
# Main PID: 1235 (nginx)
# Tasks: 3
# Memory: 12.3M
# CPU: 234ms
# ============================================
# PART 2: START AND STOP
# ============================================
sudo systemctl start nginx
sudo systemctl stop nginx
# ============================================
# PART 3: RESTART AND RELOAD
# ============================================
sudo systemctl reload nginx
# Applies the configuration without downtime.
sudo systemctl restart nginx
# Stops and starts. Brief downtime.
# ============================================
# PART 4: ENABLE AND DISABLE
# ============================================
sudo systemctl enable nginx
# Configured to start at boot.
sudo systemctl disable nginx
# Not started at boot.
sudo systemctl enable --now nginx
# Enable and start in one command.
# ============================================
# PART 5: CHECK THE STATES
# ============================================
systemctl is-active nginx
# active
systemctl is-enabled nginx
# enabled
# Active and enabled are independent.
# ============================================
# PART 6: LIST SERVICES
# ============================================
systemctl list-units --type=service
systemctl list-units --state=failed
systemctl list-unit-files --type=service
# ============================================
# PART 7: READ THE LOG
# ============================================
journalctl -u nginx -n 20
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -p err
# ============================================
# PART 8: EDIT A UNIT
# ============================================
sudo systemctl edit nginx
# Creates /etc/systemd/system/nginx.service.d/override.conf
# Inside:
# [Service]
# RestartSec=10s
sudo systemctl daemon-reload
sudo systemctl restart nginx
# ============================================
# PART 9: VIEW THE UNIT
# ============================================
systemctl cat nginx
# Shows the package unit and the overrides.
systemctl show nginx -p ActiveState -p SubState
# ActiveState=active
# SubState=running
# ============================================
# PART 10: MASK A SERVICE
# ============================================
sudo systemctl mask nginx
# Completely disabled. Cannot be started.
sudo systemctl unmask nginx
# Re-enables the ability to start.
# ============================================
# PART 11: DIAGNOSE A FAILURE
# ============================================
systemctl status nginx
# Active: failed
journalctl -u nginx -xe
# Shows the recent entries with explanations.
# The error message is in the output.
# ============================================
# PART 12: WHAT NOT TO DO
# ============================================
# Don't edit the package's unit file directly
# Use systemctl edit.
# Don't forget daemon-reload after editing
# The change is not applied.
# Don't confuse start with enable
# start is runtime, enable is boot.
# Don't restart when reload works
# reload avoids downtime.
# Don't ignore the log
# The failure reason is in journalctl.
# Don't mask a service without understanding
# mask prevents it from ever starting.The twelve parts cover the status, the lifecycle, enable/disable, state queries, listing, the log, editing, viewing, masking, failure diagnosis, and the anti-patterns.
Quick Reference
Lifecycle Commands
| Command | Effect |
|---|---|
systemctl start unit | Start now |
systemctl stop unit | Stop now |
systemctl restart unit | Stop then start |
systemctl reload unit | Re-read config |
systemctl try-restart unit | Restart if running |
systemctl reload-or-restart unit | Reload if possible, else restart |
systemctl kill unit | Send signal |
Boot State
| Command | Effect |
|---|---|
systemctl enable unit | Start at boot |
systemctl disable unit | Do not start at boot |
systemctl enable --now unit | Enable and start |
systemctl mask unit | Prevent starting entirely |
systemctl unmask unit | Allow starting |
Query Commands
| Command | Effect |
|---|---|
systemctl status unit | Show state and log |
systemctl is-active unit | Active state |
systemctl is-enabled unit | Enable state |
systemctl list-units | Loaded units |
systemctl list-unit-files | Installed units |
systemctl cat unit | Show unit file |
systemctl show unit | Show properties |
Journal Commands
| Command | Effect |
|---|---|
journalctl -u unit | Service log |
journalctl -u unit -n 20 | Last 20 lines |
journalctl -u unit -f | Follow |
journalctl -u unit --since "1 hour ago" | Time range |
journalctl -u unit -p err | Errors only |
journalctl -xe | Recent with explanations |
Edit Cycle
| Step | Command |
|---|---|
| 1. Edit | sudo systemctl edit unit |
| 2. Reload units | sudo systemctl daemon-reload |
| 3. Apply | sudo systemctl restart unit |
Active vs Enabled
| Active | Enabled | State |
|---|---|---|
| Yes | Yes | Running and starts at boot |
| Yes | No | Running but does not start at boot |
| No | Yes | Stopped but starts at boot |
| No | No | Stopped and does not start at boot |
Best Practices
✅ Do This:
# Check the status first
systemctl status nginx # ✅
# Use reload when the service supports it
sudo systemctl reload nginx # ✅
# Enable for boot, start for now
sudo systemctl enable --now nginx # ✅
# Read the log for the failure
journalctl -u nginx -xe # ✅
# Use systemctl edit for overrides
sudo systemctl edit nginx # ✅
# Reload after editing
sudo systemctl daemon-reload && sudo systemctl restart nginx # ✅
# Check the active and enabled states separately
systemctl is-active nginx && systemctl is-enabled nginx # ✅
# Use --no-pager in scripts
systemctl --no-pager list-units # ✅❌ Don’t Do This:
# Don't edit the package's unit file
vim /lib/systemd/system/nginx.service # use edit # ⚠️
# Don't forget daemon-reload
sudo systemctl edit nginx && sudo systemctl restart nginx # stale # ⚠️
# Don't confuse start and enable
sudo systemctl start nginx # does not start at boot # ⚠️
# Don't restart when reload works
sudo systemctl restart nginx # unnecessary downtime # ⚠️
# Don't ignore a failed service
# The capability it provides is broken # ⚠️
# Don't mask without understanding
sudo systemctl mask nginx # prevents any start # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
| Start vs enable confused | Does not start at boot | enable --now |
Forgot daemon-reload | Change not applied | Run after editing |
| Edited the package unit | Lost on upgrade | systemctl edit |
| Restart instead of reload | Unnecessary downtime | reload if supported |
| Log not checked | Cause unknown | journalctl -u |
is-active without checking | Wrong assumption | Check both states |
| Mask confused with disable | Cannot start | unmask to revert |
| Unit name typo | Unit not found | list-units for names |
Real-World Examples
1. Check status
systemctl status ssh2. Start and enable
sudo systemctl enable --now nginx3. Reload config
sudo systemctl reload nginx4. Restart
sudo systemctl restart nginx5. Stop and disable
sudo systemctl disable --now nginx6. Read the log
journalctl -u nginx -n 507. Follow the log
journalctl -u nginx -f8. Edit a unit
sudo systemctl edit nginx9. List failed units
systemctl list-units --state=failed10. Diagnose
systemctl status nginx && journalctl -u nginx -xeVisual: Active vs Enabled
┌──────────────────────────────────────────────────────────┐
│ ACTIVE STATE (running now) │
│ systemctl start → active │
│ systemctl stop → inactive │
│ systemctl restart → active (new process) │
│ │
├──────────────────────────────────────────────────────────┤
│ ENABLED STATE (starts at boot) │
│ systemctl enable → enabled │
│ systemctl disable → disabled │
│ │
├──────────────────────────────────────────────────────────┤
│ THE TWO ARE INDEPENDENT │
│ │
│ Active Enabled Result │
│ ────── ─────── ────────────────────────── │
│ Yes Yes Running, starts at boot │
│ Yes No Running, does not start at boot │
│ No Yes Stopped, will start at boot │
│ No No Stopped, will not start at boot │
│ │
│ enable --now combines both. │
│ │
└──────────────────────────────────────────────────────────┘Visual: reload vs restart
┌──────────────────────────────────────────────────────────┐
│ reload │
│ │
│ nginx (running) ──► ExecReload ──► nginx (running) │
│ │
│ No downtime. The service re-reads its configuration. │
│ Only supported services can do this. │
│ │
├──────────────────────────────────────────────────────────┤
│ restart │
│ │
│ nginx (running) ──► ExecStop ──► stopped │
│ │ │
│ ▼ │
│ ExecStart ──► nginx (running) │
│ │
│ Brief downtime. The process is replaced. │
│ Required for changes that cannot be reloaded. │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Edit Cycle
┌──────────────────────────────────────────────────────────┐
│ 1. sudo systemctl edit nginx │
│ │ │
│ └── creates /etc/systemd/system/nginx.service.d/ │
│ override.conf │
│ │
│ 2. Edit the override │
│ │ │
│ └── [Service] │
│ RestartSec=10s │
│ │
│ 3. sudo systemctl daemon-reload │
│ │ │
│ └── systemd re-reads the unit files │
│ │
│ 4. sudo systemctl restart nginx │
│ │ │
│ └── the new definition is applied │
│ │
│ Skipping step 3 means the restart uses the old │
│ definition. │
│ │
└──────────────────────────────────────────────────────────┘Visual: The Journal
┌──────────────────────────────────────────────────────────┐
│ journalctl -u nginx │
│ │
│ Filters: │
│ -u unit → one service │
│ -n N → last N lines │
│ -f → follow │
│ --since TIME → time range │
│ -p err → priority │
│ -x → explanations │
│ -e → jump to end │
│ │
│ Common: │
│ journalctl -u nginx -xe │
│ → recent entries with explanations │
│ │
│ The fastest way to see why a service failed. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Diagnosing a Failure
┌──────────────────────────────────────────────────────────┐
│ systemctl status nginx │
│ └── Active: failed │
│ │
│ journalctl -u nginx -xe │
│ └── the error message │
│ │
│ Common messages and fixes: │
│ "Address already in use" │
│ → ss -tlnp | grep :80 │
│ │
│ "Permission denied" │
│ → check the user and the file │
│ │
│ "No such file or directory" │
│ → check ExecStart │
│ │
│ "syntax error" │
│ → validate the config │
│ │
│ The log is the first place to look. │
│ │
└──────────────────────────────────────────────────────────┘Summary
| Command | Purpose |
|---|---|
systemctl start | Start now |
systemctl stop | Stop now |
systemctl restart | Stop and start |
systemctl reload | Re-read config |
systemctl enable | Start at boot |
systemctl disable | Do not start at boot |
systemctl mask | Prevent any start |
systemctl status | Show state and log |
systemctl is-active | Active state |
systemctl is-enabled | Enable state |
systemctl daemon-reload | Re-read units |
journalctl -u | Service log |
| State | Command |
|---|---|
| Active | is-active |
| Enabled | is-enabled |
| Failed | list-units --state=failed |
Key takeaways:
systemctlis the single interface to the init system — it manages the lifecycle, the boot state, and the queries for every unit- Active and enabled are independent states —
startchanges the active state,enablechanges the boot state, and a service can be in any combination reloadre-reads the configuration without stopping — it is preferred overrestartwhen the service supports it, because there is no downtimerestartis required for changes that cannot be reloaded — a port change, a user change, or a library change- The
--nowflag combines enable and start —enable --nowis the convenience form for both decisions systemctl editcreates an override — the package’s unit file is not modified, and the customization survives package upgradesdaemon-reloadis required after editing a unit — systemd caches the unit definitions, and the reload is the explicit signal to re-readjournalctl -u unit -xeis the diagnostic command — it shows the recent entries with explanations and is the first thing to run after a failuremaskis stronger thandisable— a masked unit cannot be started at all, even as a dependency- The status output shows both states — the “Loaded” line shows enabled or disabled, and the “Active” line shows active or inactive
Remember: systemctl is the command that runs the system. Start, stop, restart, reload, enable, disable, mask, and query — the subcommands are the vocabulary, and the states are the model. Active is runtime, enabled is boot, and the two are independent. The systemctl edit and daemon-reload cycle is how a unit is customized, and journalctl -u -xe is how a failure is diagnosed. Knowing the commands and the states 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!