Managing services with systemd

Manage Linux services professionally with systemd: learn start, stop, enable, status commands and reading logs with journalctl through real examples and practical troubleshooting.

6 min Updated 20 Aug 2026

Why is systemd the standard for service management in Linux?

If you have managed a Linux server, you are almost certain to have dealt with systemd. This system has replaced SysVinit as the service and process manager (init system) in most modern distributions such as Ubuntu, Debian, CentOS, and Rocky Linux. Unlike older methods that ran simple scripts, systemd allows you to start services in parallel, manage dependencies, see the exact status of each service, and review unified logs with journalctl.

In this article, instead of theoretical explanations, we will go straight to practical commands. You will learn how to start, stop, enable, and disable a service, check its status, and troubleshoot common issues by reading logs. This knowledge is essential for any server administrator working with web servers, databases, or custom applications.

Getting Started with systemctl: Basic Commands

The main tool for managing systemd is the systemctl command. This command allows you to work with systemd units; units can be services (.service), sockets (.socket), timers (.timer), and more. In this section, we will focus on services.

Starting and Stopping a Service

To start a service, use the start subcommand:

sudo systemctl start nginx

This command immediately runs the nginx service, but does not enable it to start on boot. To stop the service:

sudo systemctl stop nginx

If the service is unresponsive and you need to force-stop it, you can use kill, which sends the SIGKILL signal:

sudo systemctl kill -s SIGKILL nginx

Important note: The stop command stops the service gracefully, giving it a chance to release resources. Use the kill command only when the service is truly stuck.

Enabling and Disabling a Service on Boot

To have a service start automatically when the server boots, you need to enable it:

sudo systemctl enable nginx

This command creates a symbolic link in the /etc/systemd/system/multi-user.target.wants/ directory. To disable it:

sudo systemctl disable nginx

If you want to both start the service now and have it enabled on boot, you can combine the two commands:

sudo systemctl enable --now nginx

This method is very efficient and is also common in automation scripts.

Checking Service Status

The status command provides comprehensive information about a service:

systemctl status nginx

The output of this command includes the following:

  • Current status (active, inactive, failed)
  • Process ID (PID) and runtime
  • Memory usage
  • Latest service logs
  • Unit file path

To quickly check whether a service is active or not, use the is-active option:

systemctl is-active nginx

The output of this command is either active, inactive, or failed. This command is very useful in monitoring scripts.

Reading Logs with journalctl

One of the biggest advantages of systemd over older methods is log unification. Instead of searching through separate files in /var/log/, you can view all logs with journalctl.

Viewing Logs for a Specific Service

To see the logs for the nginx service:

journalctl -u nginx

This command displays all logs related to the nginx unit from the beginning of recording. To see only the last 50 lines:

journalctl -u nginx -n 50

To follow logs in real-time (like tail -f):

journalctl -u nginx -f

This option is very useful when troubleshooting an ongoing issue.

Filtering by Time

To see logs for a specific time range, use the --since and --until options:

journalctl -u nginx --since "2025-01-15 10:00:00" --until "2025-01-15 11:00:00"

You can also use relative expressions:

journalctl -u nginx --since "1 hour ago"

This method is excellent for finding errors that occurred within a specific timeframe.

Filtering by Priority

Logs have priority levels (from 0 for emergency to 7 for debug). To see only errors and critical messages:

journalctl -u nginx -p err

This command shows only messages with priority err (3) or higher. To see all messages from debug upward:

journalctl -u nginx -p debug

Common Troubleshooting: When a Service Fails

One of the most common issues is the failed status. When a service does not start, the first step is to check its status:

systemctl status nginx

The output usually includes an error message like Failed to start A high performance web server. To see more details, check the logs:

journalctl -u nginx -n 30 --no-pager

The --no-pager option displays the output without pagination and is useful for scripts.

Common Issue: Port Already in Use

If your service cannot bind to the desired port, you will see an error like Address already in use. To find the process occupying the port:

sudo ss -tulpn | grep :80

Then you can stop the interfering process or change the service port.

Common Issue: Permission Denied Error

If your service does not have access to a specific file or directory, a Permission denied error will appear in the logs. This issue is usually caused by incorrect file ownership. Fix the ownership with the following command:

sudo chown -R www-data:www-data /var/www/html

Always make sure the service runs with the correct user (here www-data). This user is defined in the service unit file.

Managing Unit Files

Each service in systemd has a unit file, usually located in /etc/systemd/system/ or /lib/systemd/system/. To view the contents of a service's unit file:

systemctl cat nginx

To edit the unit file without opening it directly:

sudo systemctl edit nginx

This command creates an override file that applies your settings without modifying the original file. This method is much safer because it does not break the main package updates.

Creating a Custom Service

Suppose you have a Python script that needs to run as a service. Create a unit file at /etc/systemd/system/myapp.service:

[Unit]
Description=My Custom Python Application
After=network.target

[Service]
Type=simple
User=myuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Then reload systemd and enable the service:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

The Restart=on-failure option causes the service to automatically restart after 5 seconds if it encounters an error. This feature is very useful for increasing the stability of critical applications.

Advanced Tips and Practical Tricks

Managing Multiple Services Simultaneously

You can manage multiple services with a single command:

sudo systemctl start nginx mysql php-fpm

This command starts all three services in order.

Viewing All Active Services

To see a list of all active services on the system:

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

To see failed services:

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

Restarting a Service

To apply changes to service settings, restart it:

sudo systemctl restart nginx

If you only want to reload the configuration file without a full interruption, use reload:

sudo systemctl reload nginx

The reload command is much better because it applies new settings without stopping the service. However, note that not all services support this feature.

Conclusion

Managing services with systemd is a skill that every server administrator should master. By mastering the systemctl and journalctl commands, you can effectively manage services, troubleshoot issues faster, and increase the stability of your server. If you are looking for a secure and reliable hosting environment to run your services, ServerNet's virtual and dedicated servers with full systemd support can be a suitable option.

Practice, experiment with unit files, and always back up your current settings before major changes. Professional service management is the difference between a stable server and one full of problems.

Was this page helpful?