When a service stops responding
You reboot your Fedora machine and the desktop loads, but your web server refuses to connect. Or you run a background task and it silently dies. You need to know whether the service is running, why it stopped, and what systemd thinks about it. The terminal gives you the answer in one command.
What systemctl status actually shows you
systemctl status does not just check if a process is alive. It queries the systemd unit database, reads the current state machine, and pulls the last few log lines from the journal. Think of it as a medical triage report. It tells you whether the patient is breathing, what the vital signs say, and what the last symptom was. You do not need to hunt through /var/log or attach a debugger. The state machine and the journal are already linked.
Systemd tracks every service as a unit. Each unit has a lifecycle. It moves from loaded to activating to active, or it drops to failed. The status command reads that lifecycle and prints a snapshot. It also attaches the most recent journal entries for that unit. This saves you from running two separate commands. You get the state and the context in one view.
Systemd unit files live in two places. Files in /usr/lib/systemd/system/ ship with packages. Files in /etc/systemd/system/ are yours to modify. Fedora follows the drop-in convention. You never edit /usr/lib/. You create a directory in /etc/systemd/system/<unit>.d/ and place override files there. The status command shows which directory systemd actually loaded. If you see /usr/lib/ in the Loaded: line, your custom changes are not applied yet. Run systemctl daemon-reload after editing /etc/. The daemon must rescan the filesystem to pick up new paths.
How to read the output
Run the command against a known service to see the full layout. Here is how to check whether the SSH daemon is running and what systemd reports about its resources.
systemctl status sshd.service
# The .service suffix is optional but prevents ambiguity with timers or sockets.
# Omit --no-pager if you want to scroll through long output with space and q.
The terminal prints a structured block. Here is what a healthy service looks like.
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-10-14 09:21:03 UTC; 2h ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1245 (sshd)
Tasks: 1 (limit: 2282)
Memory: 4.2M
CPU: 145ms
CGroup: /system.slice/sshd.service
└─1245 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
Read the block from top to bottom. The first line shows the unit name and the human-readable description. The Loaded: line tells you whether systemd found the unit file and whether it is set to start at boot. enabled means the service will launch automatically. preset: enabled is a Fedora convention that marks the default boot behavior for that package.
The Active: line is the most important. active (running) means the main process is alive and doing work. active (exited) means the service ran once, finished its job, and closed cleanly. This is normal for one-shot services like firewalld-reload. failed means systemd tried to start it, the process crashed, or a dependency broke. activating means systemd is waiting for a condition, usually a network interface or a mounted filesystem.
The Main PID: line shows the process ID. If you need to send a signal or attach a debugger, this is the number you use. The Tasks:, Memory:, and CPU: lines give you resource limits and current usage. Fedora sets default cgroup limits to prevent a runaway service from starving the rest of the system. If you see Memory: 1.2G on a service that should use megabytes, you have a leak.
The CGroup: tree shows the actual processes spawned by the unit. Systemd isolates services in cgroups. Every child process appears under this tree. If you see extra processes that do not belong to the service, the unit file is missing a PrivateTmp= or ProtectSystem= directive.
The journal excerpt follows the block. It shows the last ten lines by default. These lines are pulled from journald. They contain the exact error messages, warnings, and startup confirmations. Read them before you change configuration files. The journal tail tells you whether the failure is a missing config file, a permission denied error, or a port conflict.
Always check status before you restart. Restarting a failed service without reading the status just repeats the failure.
Useful flags for noisy terminals
The default output truncates long log lines and hides older entries. You will need flags when debugging production systems or services that spam the journal. Here is how to force full line width and increase the journal tail.
systemctl status -l -n 50 nginx.service
# The -l flag disables line wrapping so long paths and stack traces stay readable.
# The -n flag changes the journal tail from 10 lines to 50 lines.
# Combine them when a service crashes during startup and dumps a long traceback.
Use --no-pager when you pipe the output to grep or save it to a file. The pager intercepts stdout and breaks pipes. Use --full when you need to see truncated environment variables or long command-line arguments in the CGroup tree. These flags do not change the underlying state. They only adjust what the terminal renders.
Run journalctl -xe when the status tail is too short. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Verify it worked
After you fix a configuration file or install a missing dependency, you need a machine-readable way to confirm the state changed. The status command is great for humans. Scripts need exit codes.
systemctl is-active sshd.service
# Returns "active" on success and exits with code 0.
# Returns "inactive", "failed", or "activating" on other states.
# Non-zero exit codes let bash if-statements branch correctly.
Run this command in a terminal. If it prints active and returns you to the prompt, the service is healthy. If it prints failed, the service is still down. You can also check the Loaded: state independently.
systemctl is-enabled sshd.service
# Checks whether the unit is symlinked in the boot target.
# Returns "enabled", "disabled", "static", or "masked".
# Masked units cannot be started until you unmask them.
Use is-active for runtime health checks. Use is-enabled for boot configuration audits. Combine them in a monitoring script if you need automated alerts.
Run is-active in your cron jobs. Human-readable output breaks parsers.
Common pitfalls and what the error looks like
The status command will refuse to show output if you type the unit name wrong. Systemd does not guess. If you run systemctl status nginx, it prints Unit nginx.service could not be found. The correct name on Fedora is nginx.service. Some packages use different names than the binary. httpd is the Apache service on Fedora, not apache2.
You will also see services stuck in activating (start). This usually means a dependency is missing. The journal tail will show Dependency failed for ... or Job ... failed because a timeout was exceeded. Check the Requires= or After= lines in the unit file. Do not force the start with --no-block. The dependency exists for a reason.
SELinux denials often masquerade as service failures. The service starts, tries to bind a port or read a config file, and gets blocked. The status output shows active (running) but the application logs show Permission denied. Run journalctl -t setroubleshoot to see the actual denial. The one-line summary tells you which boolean to toggle or which file context to fix. Disabling SELinux hides the problem and breaks the security model.
If you see [FAILED] Failed to start ... during boot, your network configuration probably references a missing interface name. Fedora uses predictable network interface names like enp3s0. Old configs still reference eth0. The service waits for eth0, times out, and drops to failed. Update the interface name in /etc/NetworkManager/system-connections/ or in the service unit file.
Trust the journal tail. Manual file edits drift, snapshots stay.
When to use status versus other tools
Use systemctl status when you need a quick snapshot of a single service state and its recent logs. Use journalctl -u <unit> when you need to search the full history of a service across reboots. Use ps aux | grep <process> when you need to inspect command-line arguments or environment variables that systemd hides. Use systemctl list-units --type=service --state=failed when you want to audit every broken service on the system at once. Stay on systemctl status for daily troubleshooting. Switch to journalctl when the last ten lines are not enough.