Linux

Systemctl Commands: Complete Cheatsheet for Managing Linux Services

This cheatsheet compiles key systemctl commands to efficiently manage services, targets, and logs in Linux. After studying, you'll quickly diagnose and control system components.

Updated at February 15, 2026
10-15 min
Easy
FixPedia Team
Применимо к:Ubuntu 20.04+Debian 10+CentOS 8+Fedora 30+

Introduction

Systemctl is the primary utility for managing systemd, which is the standard init system in most modern Linux distributions (such as Ubuntu, Debian, CentOS, Fedora). With it, you can control services, targets, and other system components, perform diagnostics, and configure autostart. This cheat sheet compiles the most frequently used systemctl commands so you can quickly perform administrative tasks without spending time searching through documentation.

Requirements

Before you begin, ensure that:

  • Your system uses systemd. Check with the pidof systemd or systemctl --version command. If the command is not found, you may be using an alternative init system (e.g., OpenRC or SysVinit).
  • You have sudo privileges to execute commands that change service states (start, stop, enable autostart). Without administrator rights, some operations will be unavailable.
  • You are familiar with basic terminal usage and understand what a service is in the Linux context.

Service Management

Basic commands for managing service units:

# Start the service
sudo systemctl start service_name

# Stop the service
sudo systemctl stop service_name

# Restart the service (full process restart)
sudo systemctl restart service_name

# Reload with SIGHUP signal (if the service supports it)
sudo systemctl reload service_name

# Check if the service is active (returns "active" or "inactive")
systemctl is-active service_name

Example: To start the Nginx web server, run sudo systemctl start nginx. To stop it, use sudo systemctl stop nginx.

Checking Service Status

To get detailed information about a service, including its state, PID, memory usage, and recent log entries:

# Show full service status
systemctl status service_name

# Check if autostart is enabled (returns "enabled" or "disabled")
systemctl is-enabled service_name

The status command outputs the service description, last start time, process PID (if active), and the latest lines from the systemd journal. This is the first step when diagnosing issues.

Managing Autostart

Control which services start automatically at boot:

# Enable autostart for the service (creates a symlink)
sudo systemctl enable service_name

# Disable autostart
sudo systemctl disable service_name

# Check autostart status
systemctl is-enabled service_name

When enabling autostart, systemd creates a link in /etc/systemd/system/ pointing to the unit file in /lib/systemd/system/ or /etc/systemd/system/. This ensures the service will start on the next boot.

Working with Targets

Targets are analogous to runlevels in SysV init. They define the system state (e.g., multi-user mode or graphical interface):

# Switch to a target (e.g., multi-user mode without GUI)
sudo systemctl isolate multi-user.target

# Set the default target (at boot)
sudo systemctl set-default graphical.target

# Show the current default target
systemctl get-default

Common targets:

  • poweroff.target — system shutdown.
  • rescue.target — rescue mode (single user, minimal services).
  • multi-user.target — multi-user mode without a graphical interface (similar to runlevel 3).
  • graphical.target — multi-user mode with a graphical interface (similar to runlevel 5).
  • reboot.target — system reboot.

Viewing Logs

Systemd integrates with the journalctl log. For logs of a specific service:

# Show all entries for the service
sudo journalctl -u service_name

# Follow logs in real time (similar to tail -f)
sudo journalctl -u service_name -f

# Show entries from the last hour
sudo journalctl -u service_name --since "1 hour ago"

# Clean logs (caution! deletes old entries)
sudo journalctl --vacuum-time=3d  # delete entries older than 3 days

journalctl provides powerful filters: by time, unit, priority, etc. For example, sudo journalctl -p err will show only errors.

Other Useful Commands

# Reload systemd configuration (after changes to unit files)
sudo systemctl daemon-reload

# List all loaded units (filtered by type)
systemctl list-units --type=service --all

# List all installed unit files (even inactive ones)
systemctl list-unit-files

# Reboot the system
sudo systemctl reboot

# Shut down the system
sudo systemctl poweroff

# Forced reboot (emergency)
sudo systemctl emergency

Verifying Results

After executing commands, ensure services are running as expected:

  • For a running service: systemctl is-active service_name should return active.
  • For enabled autostart: systemctl is-enabled service_name should show enabled.
  • Check logs via journalctl -u service_name for errors after startup.
  • For targets: systemctl get-default will show the set default target, and systemctl list-units --type=target shows active targets.

Common Issues

Error: "Failed to start . Unit not found."

  • Cause: The service is not installed or the name is incorrect.
  • Solution: Check the service name via systemctl list-unit-files | grep -i <part_of_name>. Ensure the service package is installed (e.g., nginx for nginx.service).

Error: "Access denied" or "Permission denied"

  • Cause: The command requires superuser privileges.
  • Solution: Use sudo before the command. If sudo is unavailable, log in as root.

Service fails to start, status "failed"

  • Cause: Configuration error, missing dependencies, or port conflict.
  • Solution: Check details via systemctl status service_name and journalctl -u service_name. Ensure all dependencies listed in [Requires] and [After] are active.

Systemctl not found or command unavailable

  • Cause: The system does not use systemd (e.g., Alpine Linux, some containers, older distributions).
  • Solution: If on a distribution without systemd, use alternative tools like service (for SysVinit) or rc-service (for OpenRC). To check: cat /proc/1/comm — if it outputs systemd, then systemd is active.

Changes in configuration files not applied

  • Cause: systemd caches the configuration.
  • Solution: After editing unit files (.service), run sudo systemctl daemon-reload, then sudo systemctl restart service_name.

F.A.Q.

What is systemctl and what is it used for?
How to check if a service is running?
How to make a service start automatically at boot?
What to do if systemctl is not found?

Hints

Check service status
Manage service state
Enable and disable auto-start
View all active services
Working with targets
View logs
FixPedia

Free encyclopedia for fixing errors. Step-by-step guides for Windows, Linux, macOS and more.

© 2026 FixPedia. All materials are available for free.

Made with for the community