How to Check if a Service Is Running in Linux (systemctl)

The fastest check on any modern distribution (Ubuntu, Debian, RHEL, Rocky, Alma, Fedora) is:

systemctl is-active nginx

It prints active and exits with code 0 when the service is running; anything else (inactive, failed, activating) returns a non-zero exit code. That makes it ideal for scripts:

if systemctl is-active --quiet nginx; then
  echo "nginx is running"
else
  echo "nginx is NOT running"
fi

For monitoring all services continuously, see Service Monitoring.

The Essential Commands

# Yes/no answer (scriptable)
systemctl is-active nginx

# Full status: state, PID, memory, last log lines
systemctl status nginx

# Will it start on boot?
systemctl is-enabled nginx

# Every running service on the host
systemctl list-units --type=service --state=running

# Every failed service on the host
systemctl --failed

Reading systemctl 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-09-21 10:00:00 UTC

Field	Value	Meaning
Active	active (running)	Running normally
Active	active (exited)	One-shot unit finished successfully - nothing to keep running
Active	inactive (dead)	Stopped
Active	failed	Crashed or exited with an error - check journalctl -u <name>
Active	activating (auto-restart)	Crash-looping; systemd keeps restarting it
Loaded	enabled / disabled	Starts / does not start on boot

Without systemd (SysV init, Alpine, containers)

# SysV-style init scripts
service nginx status

# OpenRC (Alpine, Gentoo)
rc-service nginx status

# Any system: is the process alive?
pgrep -a nginx

# Is it actually listening on its port?
ss -ltnp | grep ':80 '

A running process is not the same as a working service: pgrep can succeed while the service refuses connections. Checking the port (or an HTTP endpoint) catches that case.

Common Services to Check

# Web servers
systemctl status nginx
systemctl status apache2

# Databases  
systemctl status mysql
systemctl status postgresql

# Common services
systemctl status redis
systemctl status php-fpm
systemctl status docker

Method 1: Check Systemd Service Status with systemctl Command

The most straightforward way to check if a systemd service is running on Linux is using the systemctl command. This built-in systemd utility provides detailed information about service status, including whether the service is active, enabled, or has failed.

Basic Service Status Check

To check if a specific systemd service is running, use:

systemctl status servicename

This command shows you:

• Current service state (active, inactive, failed)
• Service process ID (PID)
• Recent log entries
• Service dependencies
• Memory and CPU usage

Check if Service is Active

For a quick yes/no answer on whether a systemd service is running:

systemctl is-active servicename

This returns "active" if the service is running, or "inactive" if it's stopped.

List All Running Services

To see all currently active systemd services on your Linux server:

systemctl list-units --type=service --state=running

This comprehensive list helps you verify that all expected services are running and identify any that should be active but aren't.

Method 2: Monitor Multiple Systemd Services Simultaneously

When managing a production Linux server, you often need to monitor multiple critical services at once. Instead of checking each service individually, you can check multiple services in a single command.

Check Multiple Services Status

systemctl is-active nginx mysql redis postgresql

This command checks the status of multiple services and shows which are active and which aren't. Perfect for quick health checks of your entire service stack.

Monitor Critical Services with One Command

For servers running web applications, you might want to check:

systemctl is-active nginx php-fpm mysql redis

This ensures your web server, PHP processor, database, and cache are all running properly.

Method 3: Automated Systemd Service Monitoring with Zuzia.app

Checking services by hand works while you are logged in. Zuzia's agent keeps an eye on them when you are not.

How it works in Zuzia

• Install the Zuzia agent on the server with one command. Zuzia discovers the systemd services on the host and shows their state.
• Start, stop or restart any discovered service from the panel, without opening an SSH session.
• Pick the services that matter and choose what happens when one stops: Zuzia only notifies you, or Autopilot (paid plans) restarts it and checks it came back. You can run Autopilot in dry-run first, or approve each restart from a link in your email.
• For checks beyond systemd, save the commands from this guide as a scheduled task. If a command fails, you get an alert right away by email, Slack, Discord, push (through your Pushover account) or SMS (through your Vonage account).

Setting it up

1. Add the server in the Zuzia dashboard and install the agent.
2. Open the host's Services tab, pick the services to watch and choose notify or Autopilot.
3. Choose your notification channels. Turn on maintenance mode during planned work so it doesn't trigger alerts.

Method 4: Detect Failed Systemd Services Automatically

Sometimes services don't just stop - they fail. Failed services require immediate attention as they indicate underlying problems. Systemd marks services as "failed" when they crash or encounter errors during startup.

Check for Failed Services

systemctl --failed

This command lists all systemd services that have failed, helping you quickly identify which services need attention.

Monitor Failed Services with Zuzia.app

Add this command to Zuzia.app as a scheduled task:

systemctl --failed --no-pager

Configure alerts to notify you immediately when any service fails. This proactive monitoring ensures you're aware of service problems before they impact users.

Advanced Systemd Service Monitoring Techniques

Track Service Restart Frequency

Services that restart frequently may indicate underlying problems. Monitor restart counts:

systemctl show servicename -p NRestarts

Add this to Zuzia.app to track which services restart most often and identify potential stability issues.

Monitor Service Resource Usage

Check how much memory and CPU services are consuming:

systemctl status servicename | grep -E "Memory|CPU"

This helps identify services consuming excessive resources that might need optimization.

Check Service Dependencies

Understanding service dependencies helps troubleshoot why services might not start:

systemctl list-dependencies servicename

If a dependent service fails, it can prevent other services from starting properly.

Real-World Use Cases for Systemd Service Monitoring

Web Server Monitoring

For web servers running Nginx or Apache, monitoring service status is critical:

# Check web server status
systemctl is-active nginx
systemctl is-active apache2

# Monitor PHP-FPM if using PHP
systemctl is-active php-fpm

Set up Zuzia.app to check these services every 5 minutes and alert immediately if any stop running.

Database Service Monitoring

Database services like MySQL, PostgreSQL, or MariaDB must stay running:

# Check database status
systemctl is-active mysql
systemctl is-active postgresql
systemctl is-active mariadb

Database downtime can cause complete application failure, so these services require constant monitoring.

Cache and Queue Service Monitoring

Services like Redis, Memcached, or RabbitMQ often run in the background but are critical for application performance:

# Check cache services
systemctl is-active redis
systemctl is-active memcached

# Check queue services
systemctl is-active rabbitmq-server

These services might not cause immediate failures but can significantly degrade application performance when down.

Best Practices for Systemd Service Monitoring

1. Monitor Critical Services Frequently

Check mission-critical services every 5-15 minutes. Less critical services can be checked every 30-60 minutes.

2. Set Up Multiple Alert Channels

Don't rely on a single notification method. Configure email, webhook, and SMS alerts for critical service failures.

3. Track Historical Service Status

Use Zuzia.app's historical data storage to identify patterns. Services that fail at specific times might indicate scheduled maintenance issues or resource constraints.

4. Monitor Service Dependencies

If a service depends on others, monitor the entire dependency chain. A database failure can cascade to application services.

5. Use AI Analysis for Pattern Detection

On paid plans, AI can read the output of your scheduled tasks and commands, explain it in plain language and alert you only when it spots a problem. Metric alerts work without AI: Zuzia alerts when CPU, RAM or load drifts from the server's normal and forecasts when a disk will fill up.

Troubleshooting Common Systemd Service Issues

Service Shows as Active but Not Responding

Sometimes a service shows as "active" but isn't actually functioning. Check service logs:

journalctl -u servicename -n 50

This shows the last 50 log entries, helping identify why a service might not be working despite showing as active.

Service Keeps Stopping

If a service repeatedly stops, check for:

• Resource constraints (memory, CPU, disk)
• Configuration errors
• Dependency failures
• Permission issues

Use Zuzia.app to monitor resource usage and identify what's causing the service to stop.

Service Won't Start

When a service won't start:

1. Check service status: systemctl status servicename
2. Review logs: journalctl -u servicename
3. Verify dependencies: systemctl list-dependencies servicename
4. Check configuration: systemctl cat servicename

FAQ: Common Questions About Checking Systemd Service Status

How often should I check if systemd services are running?

For production servers, check critical services every 5-15 minutes. Use Zuzia.app automated monitoring to check services continuously without manual intervention. Less critical services can be checked every 30-60 minutes.

What's the difference between active and enabled systemd service status?

"Active" means the service is currently running. "Enabled" means the service will start automatically at boot. A service can be active but not enabled (won't start on reboot) or enabled but not active (configured to start but currently stopped).

How do I check if a systemd service is running on a remote Linux server?

Use SSH to connect to the remote server and run systemctl status servicename. For automated remote monitoring, use Zuzia.app which can execute commands on remote servers through its agent and store results in the database for centralized monitoring.

Can I check systemd service status without SSH access?

Yes, if you have Zuzia.app agent installed on the server, you can check service status through the Zuzia.app dashboard without direct SSH access. Commands are executed through the agent and results are stored in the database.

What should I do if a critical systemd service stops running?

First, check service logs to identify the cause: journalctl -u servicename -n 100. Then try restarting the service: systemctl restart servicename. If the service keeps stopping, investigate resource constraints, configuration errors, or dependency issues. Use Zuzia.app to monitor the service and receive alerts when it stops again.

How can I monitor systemd service status across multiple Linux servers?

Zuzia.app allows you to add multiple servers and monitor systemd service status across all of them simultaneously. Each server executes commands independently, and all results are stored in Zuzia.app's database for centralized monitoring and analysis.

Does Zuzia.app use AI to analyze systemd service status patterns?

On paid plans, AI can read the output of your scheduled tasks and commands, explain it in plain language and alert you only when it spots a problem. Metric alerts work without AI: Zuzia alerts when CPU, RAM or load drifts from the server's normal and forecasts when a disk will fill up.

Related guides, recipes, and problems

• Related guides

  • Complete Linux server monitoring and automation: guides--server-metrics-monitoring-automated.md
  • Performance and uptime best practices: guides--server-performance-optimization-guide.md

• Related recipes

  • Monitor running systemd services continuously: recipes--monitor-running-services-systemd.md, recipes--monitor-system-services-status-linux.md
  • Detect failed services and restarts: recipes--monitor-failed-systemd-services.md
  • Check all system services status one time: recipes--check-all-system-services-status.md

• Related problems

  • Service not running or keeps restarting: problems--service-not-running-linux.md, problems--service-keeps-stopping-restarting.md
  • Website or API unavailable because backend services failed: problems--website-unavailable-down.md