Managing Linux Services with systemd

On most modern Linux distributions, systemd is the central nervous system that boots your machine, starts your services, and keeps them running. If you work with servers, homelabs, or DevOps pipelines, learning to drive systemd with confidence is essential.

In this guide, you will not only see the basic commands, but also learn how to think and operate like a Linux engineer when managing services: checking health, controlling startup, reading logs, and writing your own services for scripts and applications.

Quick Reference: What systemctl Is For

The systemctl command is your main interface to systemd. Use it to inspect, start, stop, enable, disable, and debug services.

1. Inspecting Service Health

When something is not working, your first move should almost always be to check the service status:

sudo systemctl status ssh

From this single command, you get:

• Whether the service is active, inactive, failed, or reloading
• When it was last started and how long it has been running
• The main process ID (PID) and basic resource information
• Recent log lines pulled straight from the systemd journal

This makes systemctl status a powerful starting point for troubleshooting. For a wider view without paging:

sudo systemctl status apache2 --no-pager

2. Starting, Stopping, and Restarting Services Safely

Basic lifecycle actions are straightforward, but it is important to choose the right one for the situation:

sudo systemctl start ssh
sudo systemctl stop ssh
sudo systemctl restart ssh

• start – launch the service if it is not running.
• stop – gracefully shut it down.
• restart – stop and start, typically after configuration changes.

When supported by the service, a reload is even better than a restart because it applies new configuration without dropping existing connections:

sudo systemctl reload nginx

You will use restart during deployments and reload during configuration updates where you want to avoid unnecessary downtime.

3. Enabling and Disabling Services at Boot

A crucial part of managing a Linux system is deciding what runs automatically on boot. You do not want services starting that you never use, and you do not want critical ones to be forgotten.

sudo systemctl enable ssh
sudo systemctl disable ssh
systemctl is-enabled ssh

• enable – create the appropriate symlinks so the service starts at boot.
• disable – remove those symlinks so the service no longer starts automatically.
• is-enabled – quickly check if a service is configured to start at boot.

To see all services and their boot status:

systemctl list-unit-files --type=service

4. Viewing Running and Failed Services

To get a snapshot of what is running on your system:

systemctl --type=service --state=running

During troubleshooting, you may want to focus on services that have failed:

systemctl --failed

This is especially useful on freshly booted systems or after a deployment, where you want to quickly see what did not start correctly.

5. Reading Service Logs with journalctl

While you may be used to poking around in /var/log, the systemd journal often gives you a more complete view of what is happening with a service.

sudo journalctl -u ssh

That shows the log history for the SSH service. To follow logs in real time (similar to tail -f):

sudo journalctl -u ssh -f

Filtering logs by time is extremely helpful when you know roughly when a problem started:

sudo journalctl -u docker --since "2 hours ago"
sudo journalctl -u nginx --since "2025-11-20 09:00" --until "2025-11-20 10:00"

Combining systemctl status with journalctl is the core workflow for diagnosing service issues.

6. Creating a Custom Service for Your Own App or Script

One of the most powerful features of systemd is the ability to run your own scripts or applications as first-class services with automatic restart and centralized logging.

Assume you have a Python backup script at:

/usr/local/bin/backup.py

You want it to:

• Start automatically at boot
• Restart if it crashes
• Log output to the systemd journal

Create a service file at /etc/systemd/system/backup.service:

[Unit]
Description=Nightly Backup Service
After=network-online.target

[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/backup.py
Restart=always
RestartSec=5
User=root
WorkingDirectory=/usr/local/bin

[Install]
WantedBy=multi-user.target

Then reload systemd, enable the service, and start it:

sudo systemctl daemon-reload
sudo systemctl enable backup
sudo systemctl start backup

Now you can manage it just like any other system service:

sudo systemctl status backup
sudo journalctl -u backup -f

With this pattern, any script or binary can become a managed service, benefiting from systemd’s process supervision and logging.

7. A Practical Troubleshooting Workflow

In day-to-day Linux operations, the following workflow works well when a service is misbehaving:

1. Check status for context:

   sudo systemctl status <service>

2. Follow the logs while you reproduce the problem:

   sudo journalctl -u <service> -f

3. Edit the configuration files (for example in /etc).
4. Apply the changes:

   sudo systemctl restart <service>

   or, if supported:

   sudo systemctl reload <service>

5. Verify again with status and by testing the service from the client side (web browser, SSH client, etc.).

Once this pattern becomes habit, you will move much faster and with more confidence when something goes wrong.

Final Thoughts

Mastering systemd is a core skill for Linux administrators, SREs, and DevOps engineers. It is not just a replacement for old init scripts; it is a complete framework for starting, supervising, and observing your services.

When you know how to:

• Inspect and manage service state with systemctl,
• Control which services start at boot,
• Use journalctl to dig into logs, and
• Wrap your own applications in custom unit files,

you move from simply using Linux to truly operating it. That’s the level expected of serious Linux and DevOps professionals.