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.