- Joined
- Mar 22, 2026
- Messages
- 189
- Reaction score
- 0
Windows 10
Google Chrome 146
Systemd has become the de-facto init system for most modern Linux distributions, replacing older systems like SysVinit and Upstart. While initially met with some controversy, its powerful features for service management, parallel startup, and robust logging have made it an indispensable tool for system administrators and developers alike. This article will break down the core concepts of Systemd, focusing on services, targets, and timers, and show you how to leverage them effectively.
What is Systemd?
At its heart, Systemd is an init system and system manager. It's the first process started on boot (PID 1) and is responsible for managing all other processes. Its primary goals include speeding up boot time, providing on-demand service activation, and offering better dependency management.
Instead of a collection of shell scripts, Systemd uses "unit files" to define how services, devices, mount points, and other system resources should be handled.
Systemd Unit Files: The Building Blocks
Unit files are configuration files that describe a resource controlled by Systemd. They are typically located in
There are several types of unit files, but we'll focus on the most common and important ones:
1. Service Units (
2. Target Units (
3. Timer Units (
Managing Services with
The
Basic Service Management:
Example:
Creating Custom Service Units
Let's create a simple Systemd service for a Python web server.
1. Create a simple Python web server (
2. Create the Systemd service unit file:
Save this file as
Explanation of sections and directives:
*
*
*
*
*
3. Reload Systemd, Enable, and Start the Service:
Now, your Python web server will run in the background, restart if it crashes, and start automatically on boot.
Scheduling Tasks with Timer Units
Timer units offer a more robust and flexible way to schedule tasks compared to traditional
1. Create a service unit for the task (
2. Create the timer unit (
3. Enable and Start the Timer:
Notice you enable and start the
Understanding Target Units
Target units (
Common Targets:
Managing Default Targets:
When you
Logging with
Systemd centralizes logging for all services and the kernel through its
Key
Example:
Conclusion
Systemd provides a powerful and consistent framework for managing services, scheduling tasks, and controlling the Linux boot process. By understanding unit files (especially services, timers, and targets) and mastering
What is Systemd?
At its heart, Systemd is an init system and system manager. It's the first process started on boot (PID 1) and is responsible for managing all other processes. Its primary goals include speeding up boot time, providing on-demand service activation, and offering better dependency management.
Instead of a collection of shell scripts, Systemd uses "unit files" to define how services, devices, mount points, and other system resources should be handled.
Systemd Unit Files: The Building Blocks
Unit files are configuration files that describe a resource controlled by Systemd. They are typically located in
/etc/systemd/system/ (for custom units), /run/systemd/system/ (for runtime units), and /usr/lib/systemd/system/ (for units provided by installed packages).There are several types of unit files, but we'll focus on the most common and important ones:
1. Service Units (
.service): Manage daemons and applications. This is what you'll use most often to start, stop, and manage background processes.2. Target Units (
.target): Group other units together, similar to runlevels in older init systems. They define specific system states (e.g., multi-user mode, graphical mode).3. Timer Units (
.timer): Used to schedule tasks, acting as a modern replacement for cron.Managing Services with
systemctlThe
systemctl command is your primary interface for interacting with Systemd.Basic Service Management:
systemctl start <service_name>: Starts a service.systemctl stop <service_name>: Stops a service.systemctl restart <service_name>: Restarts a service.systemctl reload <service_name>: Reloads a service's configuration without fully restarting it (if supported by the service).systemctl enable <service_name>: Configures a service to start automatically on boot.systemctl disable <service_name>: Prevents a service from starting on boot.systemctl status <service_name>: Shows the current status, including whether it's running, enabled, and recent log messages.systemctl is-active <service_name>: Checks if a service is running.systemctl is-enabled <service_name>: Checks if a service is enabled for boot.
Example:
Bash:
systemctl start apache2.service
systemctl enable apache2.service
systemctl status apache2.service
Creating Custom Service Units
Let's create a simple Systemd service for a Python web server.
1. Create a simple Python web server (
web_server.py):
Python:
# web_server.py
import http.server
import socketserver
import os
PORT = 8000
DIRECTORY = os.getcwd()
class Handler(http.server.SimpleHTTPRequestHandler):
def __init__(self, *args, **kwargs):
super().__init__(*args, directory=DIRECTORY, **kwargs)
with socketserver.TCPServer(("", PORT), Handler) as httpd:
print(f"serving at port {PORT} from directory {DIRECTORY}")
httpd.serve_forever()
2. Create the Systemd service unit file:
Save this file as
/etc/systemd/system/mywebapp.service.
INI:
[Unit]
Description=My Simple Python Web Application
After=network.target
[Service]
User=www-data # Run the service as this user
Group=www-data # Run the service as this group
WorkingDirectory=/opt/mywebapp/ # Directory where your script is located
ExecStart=/usr/bin/python3 /opt/mywebapp/web_server.py # Command to start the service
Restart=always # Always restart if it stops
StandardOutput=journal # Send standard output to journalctl
StandardError=journal # Send standard error to journalctl
[Install]
WantedBy=multi-user.target # Start this service when the system reaches multi-user mode
Explanation of sections and directives:
[Unit]: Contains generic information about the unit.
Description: A human-readable description.*
After: Specifies that this service should start *after* network.target is active. This ensures network is up before our web server tries to bind to a port.[Service]: Defines the behavior of the service.
User, Group: Specifies the user and group under which the service will run for security.*
WorkingDirectory: Sets the current working directory for ExecStart.*
ExecStart: The command executed to start the service. Use full paths to binaries.*
Restart: Defines when and how the service should be restarted (e.g., always, on-failure, no).*
StandardOutput, StandardError: Redirects output to journalctl.[Install]: Used bysystemctl enableto integrate the service into the boot process.
WantedBy: Specifies which target this service should be pulled in by. multi-user.target is common for server applications.3. Reload Systemd, Enable, and Start the Service:
Bash:
sudo mkdir -p /opt/mywebapp
sudo cp web_server.py /opt/mywebapp/
sudo chown -R www-data:www-data /opt/mywebapp # Ensure correct permissions
sudo systemctl daemon-reload # Reload Systemd to pick up the new unit file
sudo systemctl enable mywebapp.service
sudo systemctl start mywebapp.service
sudo systemctl status mywebapp.service
Now, your Python web server will run in the background, restart if it crashes, and start automatically on boot.
Scheduling Tasks with Timer Units
Timer units offer a more robust and flexible way to schedule tasks compared to traditional
cron jobs. They consist of two files: a .service file (describing the task to run) and a .timer file (describing when to run it).1. Create a service unit for the task (
/etc/systemd/system/mybackup.service):
INI:
[Unit]
Description=My Daily Backup Script
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_script.sh # Your backup script
Type=oneshot: Indicates the service will run a command and then exit.
2. Create the timer unit (
/etc/systemd/system/mybackup.timer):
INI:
[Unit]
Description=Run My Daily Backup Script Daily
[Timer]
OnCalendar=daily # Run once every day. Other options: hourly, weekly, Mon *-*-* 03:00:00
Persistent=true # If the system is off during a scheduled run, execute it on next boot.
[Install]
WantedBy=timers.target # Activate this timer when the system reaches the timers target
OnCalendar: Specifies the schedule. You can use various formats (e.g.,*-*-* 03:00:00for 3 AM daily,Mon,Fri 08:00for Monday and Friday at 8 AM).Persistent=true: Ensures that if the system is down when a timer is supposed to fire, it will run the service shortly after the system boots up.
3. Enable and Start the Timer:
Bash:
sudo systemctl daemon-reload
sudo systemctl enable mybackup.timer
sudo systemctl start mybackup.timer
sudo systemctl status mybackup.timer
systemctl list-timers # View all active timers
Notice you enable and start the
.timer unit, not the .service unit directly. The timer will trigger the service.Understanding Target Units
Target units (
.target) are special unit files that group other unit files together. They serve as synchronization points during the boot process and represent specific system states, much like runlevels in SysVinit.Common Targets:
multi-user.target: The standard target for servers, providing a non-graphical multi-user environment.graphical.target: Extendsmulti-user.targetby adding graphical desktop services.reboot.target,poweroff.target: Used for system shutdown and reboot.emergency.target,rescue.target: For system recovery and troubleshooting.
Managing Default Targets:
systemctl get-default: Shows the default target (e.g.,graphical.targetormulti-user.target).systemctl set-default multi-user.target: Sets the default boot target tomulti-user.target. This is often done on servers to avoid booting into a graphical environment.
When you
enable a service with WantedBy=multi-user.target, Systemd creates a symbolic link from multi-user.target.wants/mywebapp.service to your actual service file, effectively adding it to the services started when the system reaches the multi-user.target state.Logging with
journalctlSystemd centralizes logging for all services and the kernel through its
journald component. The journalctl command allows you to query and view these logs.Key
journalctl commands:journalctl: View all logs.journalctl -f: Follow new log messages in real-time (liketail -f).journalctl -u <service_name>: View logs for a specific service (e.g.,journalctl -u mywebapp.service).journalctl -u <service_name> -f: Follow logs for a specific service.journalctl --since "2 hours ago": View logs from a specific time.journalctl --since "yesterday" --until "today": View logs for a specific period.journalctl -p err: View logs with a priority of "error" or higher.journalctl --disk-usage: Check how much disk space the journal is using.
Example:
Bash:
journalctl -u mywebapp.service --since "10 minutes ago"
Conclusion
Systemd provides a powerful and consistent framework for managing services, scheduling tasks, and controlling the Linux boot process. By understanding unit files (especially services, timers, and targets) and mastering
systemctl and journalctl, you gain fine-grained control over your system's behavior, making administration more efficient and reliable. While it has a learning curve, the benefits in terms of boot speed, dependency management, and centralized logging are well worth the effort.