How to Check Systemd Service Status in Linux: The Complete Guide

Look, I’ll be straight with you: if you’re managing a Linux system and you’re not comfortable checking service status, you’re flying blind. Every production outage I’ve dealt with in the last decade started with the same question: “Is the service actually running?”

Modern Linux distributions use systemd to manage services, and the systemctl command is your window into what’s happening with every service on your system. Mastering it is non-negotiable for anyone serious about Linux administration.

What is systemd and Why Should You Care?

systemd is the init system and service manager that runs as PID 1 on most modern Linux distributions – Ubuntu, Debian, CentOS, RHEL, Fedora, Arch, and more. It replaced SysVinit, bringing parallel service startup, dependency management, and unified logging through journalctl.

Think of systemd as the conductor of an orchestra – it knows which services need to start, in what order, and how to handle failures. Every service on your system, from your web server to SSH daemon, is managed as a “unit” by systemd.

The Basic Command: systemctl status

The bread and butter command you’ll use dozens of times a day is systemctl status. Here’s the syntax:

systemctl status service-name

For example, to check if your SSH service is running:

systemctl status sshd

Or on Debian/Ubuntu systems:

systemctl status ssh

The output gives you a wealth of information – whether the service is active or inactive, its main process ID (PID), how long it’s been running, memory usage, and recent log entries. This single command answers about 80% of the “is it working?” questions that come up.

Understanding the Status Output

When you run systemctl status, the Loaded line tells you whether systemd found the service file and if it’s enabled to start at boot. The Active line is what you’re usually looking for. Here’s what the different states mean:

• active (running) – The service is up and running. This is what you want to see.
• active (exited) – The service ran successfully and completed. Common for one-time setup scripts.
• active (waiting) – The service is running but waiting for an event to trigger action.
• inactive (dead) – The service is stopped. Not necessarily a problem.
• failed – Something went wrong. Time to dig deeper.

The output also shows recent log entries. Nine times out of ten, if a service failed to start, the reason is right there in those last few lines.

Quick Status Checks for Scripting

Sometimes you don’t need the full status output – you just need a yes/no answer. For scripts and quick checks, use these simpler commands:

systemctl is-active service-name

This returns just “active” or “inactive”. Perfect for if statements in bash scripts.

systemctl is-enabled service-name

This tells you if a service is configured to start at boot – returning “enabled”, “disabled”, or “static”. I use these constantly in monitoring scripts.

Checking All Services at Once

Want to see everything that’s running on your system?

systemctl list-units --type=service

This shows you all loaded services and their current state. To see only active services, add --state=active.

Here’s one of my favorites – listing all failed services:

systemctl --failed

This command has saved me hours of troubleshooting. Instead of trying to figure out what broke, it tells you immediately which services didn’t start properly.

Troubleshooting Failed Services

When a service fails, systemctl status is your starting point, but sometimes you need more context. That’s where journalctl comes in:

journalctl -u service-name -e

The -e flag jumps to the end where the most recent entries are. To follow logs in real-time:

journalctl -u service-name -f

I’ve debugged countless service failures by watching the logs in real-time while attempting to start the service. You see exactly where it’s breaking, what configuration it’s choking on, or which dependency is missing.

Common Failure Scenarios

Most service failures fall into a few categories:

• Configuration errors – A typo in a config file, wrong file permissions, or invalid syntax. The logs usually point right to the problem.
• Missing dependencies – The service needs another service or a file that doesn’t exist.
• Port conflicts – Two services trying to bind to the same port. Checking open ports can help identify conflicts.
• Resource exhaustion – The service can’t start because the system is out of memory or disk space. Monitoring memory usage helps catch these issues.

Checking Dependencies and Configuration

One of systemd’s strengths is its dependency management. To see what a service depends on:

systemctl list-dependencies service-name

This shows you the entire dependency tree. It’s particularly useful when a service won’t start and you suspect it’s waiting for something else. You can also check reverse dependencies with --reverse to see what would be affected if you stopped a service.

To view the actual service unit file:

systemctl cat service-name

This displays the full service file content with directives like ExecStart (what command to run), Restart (when to auto-restart), and User (what user to run as).

Real-World Troubleshooting Scenarios

Service appears running but isn’t responding. Check the status, then verify the process is actually listening on the expected port. The service might have started but crashed immediately.

Critical service isn’t starting at boot. Check if it’s enabled with systemctl is-enabled. If disabled, enable it with systemctl enable service-name.

Configuration changes without downtime. Some services support systemctl reload service-name, which re-reads configuration without fully restarting.

For automated services like cron jobs, checking service status helps ensure they’re running when expected. Many modern systems have moved from cron to systemd timers – check those with systemctl list-timers.

Advanced Troubleshooting with systemd-analyze

Here’s a command that doesn’t get enough love: systemd-analyze. To verify a service file for syntax errors:

systemd-analyze verify service-name.service

This catches configuration mistakes before you try to start the service. You can also see which services are taking the longest to start:

systemd-analyze blame

If your system is booting slowly, this points you to the culprits. I’ve used it to identify services that were configured to wait for network connections that would never come, adding 90 seconds to every boot.

Monitoring Services in Production

In production environments, you need automated monitoring. I typically set up simple scripts that use systemctl is-active and alert me if critical services go down:

#!/bin/bash
SERVICE="nginx"
if ! systemctl is-active --quiet $SERVICE; then
    echo "$SERVICE is down!" | mail -s "Alert" admin@example.com
fi

Combine this with a cron job or systemd timer for basic service monitoring. When a service does fail, systemctl gives you the power to quickly diagnose and fix the issue. Combined with tools for managing processes, you can handle most service-related incidents efficiently.

Understanding Service States

Services in systemd go through various states. When you start a service, it moves from “inactive” to “activating” to “active”. If something fails during “activating”, you’ll see “failed”.

Some services have a Restart= directive that tells systemd to automatically restart them if they crash. This is great for resilience, but it can mask problems. If a service keeps restarting, check how many times it’s failed:

systemctl show service-name -p NRestarts

A high restart count suggests an underlying issue that needs attention.

Best Practices I’ve Learned

After years of managing Linux systems, here are the systemctl habits that have saved me the most time:

• Always check status before making changes. Know the current state before you restart or reconfigure anything.
• Read the logs. Don’t guess why something failed – the logs usually tell you explicitly.
• Test in non-production first. Service changes can have unexpected consequences.
• Use enable/disable thoughtfully. Only enable what you actually need at boot.
• Document your custom services. Add good descriptions and comments. Your future self will thank you.

For comprehensive guidance on systemd service management, the DigitalOcean systemctl tutorial covers everything from basics to advanced configurations. When dealing with failed services specifically, the nixCraft guide on troubleshooting failed units provides excellent debugging strategies. For ongoing optimization, check out this guide on systemd service optimization.

Wrapping Up

Knowing how to check service status with systemctl is fundamental to managing any modern Linux system. Start with the basics – systemctl status, systemctl is-active, and systemctl --failed. These three commands will handle most of your daily needs.

As you get comfortable, layer in the troubleshooting techniques: reading logs with journalctl, checking dependencies, verifying configurations. The beauty of systemd is that it gives you visibility into your entire system.

And trust me – when you’re troubleshooting at 3 AM and a quick systemctl status shows you exactly what’s broken, you’ll appreciate having these tools at your fingertips.