systemctl is the command-line tool for managing systemd, the service manager on modern Linux distributions. It controls system services, including starting, stopping, enabling, disabling, and monitoring processes.
The current stable version is systemd 258 (September 2025). Version 259 is in the release candidate stage as of November 2025. systemd 258 removes cgroup v1 support and requires kernel 5.4 or higher. System V service script support remains deprecated and scheduled for removal in systemd 260.
This guide covers essential systemctl commands, unit file structure, and troubleshooting techniques for system administrators.
What is systemctl?
systemctl interfaces with systemd to manage system services. It handles service control while systemd manages boot initialization, dependency resolution, and process supervision.
The tool operates on units – systemd’s term for manageable resources. Services (background processes) are the most common unit type. The .service suffix is optional: both systemctl start nginx.service and systemctl start nginx work identically.
Common operations include starting web servers, stopping databases, configuring boot behavior, and monitoring service health. All systemctl operations work with unit files that define service behavior.
Understanding Units and Unit Files
Units
Units are resources managed by systemd. The main types include:
- Services handle background processes like nginx, mysqld, and sshd—the most frequently managed unit type for system administrators.
- Sockets are network listeners that enable socket-based activation, starting services when network requests arrive.
- Timers schedule tasks at specific times, replacing traditional cron jobs with better integration.
- Mounts represent filesystem mount points where storage connects.
- Devices manage hardware device resources.
Unit Files
Unit files configure how systemd manages each unit. These plain-text configuration files use key-value pairs organized into sections.
Location hierarchy:
/lib/systemd/system/ contains system defaults installed with packages.
/etc/systemd/system/ holds custom configurations and overrides. Files here take priority over system defaults.
Unit files define startup procedures, dependencies, restart behavior, and boot sequence integration.
Unit File Structure
Unit files consist of three primary sections.
[Unit] Section
This section contains metadata and dependencies:
- Description provides a human-readable name for the service.
- After ensures this service starts after the specified units finish loading.
- Before ensures this service completes, before the specified units start.
- Requires creates hard dependencies. If required units fail, this service won’t start.
- Wants creates optional dependencies. This service starts even if the wanted units fail.
Example configuration:
[Unit]
Description=Nginx Web Server
After=network.target remote-fs.target
Requires=network.target
Wants=remote-fs.target
[Service] Section
This section controls service behavior:
Type defines startup behavior:
- simple – Main process runs directly from ExecStart
- forking – Process creates a child, and the parent exits
- oneshot – Script runs once and completes
ExecStart specifies the command that launches the service.
ExecReload defines the command for reloading the configuration without a full restart.
ExecStop sets the stop command. Without this, systemd sends SIGTERM to the main process.
Restart controls automatic restart:
- always – Restart regardless of exit status
- on-failure – Restart only on errors
- no – Never restart automatically
RestartSec sets the delay between restart attempts.
User and Group specify which account runs the service.
WorkingDirectory sets the process execution directory.
Example configuration:
[Install] Section
This section handles boot integration:
WantedBy specifies which target should pull in this service when enabled. Common targets include multi-user.target for console systems and graphical.target for desktop environments.
Example configuration:
[Install]
WantedBy=multi-user.target
Editing Best Practices
Use systemctl edit service-name to modify services. This creates override files in /etc/systemd/system/service-name.service.d/override.conf instead of modifying system files directly. Changes survive system updates.
For complete replacement, use systemctl edit –full service-name. This copies the entire unit file to /etc/systemd/system/ for editing.
Essential systemctl Commands
Checking Service Status
View service state, process details, and recent activity:
systemctl status nginx
Output shows whether the service is active (running), inactive (stopped), or failed, including recent log entries.
Starting Services
Start service immediately (does not persist across reboots):
systemctl start nginx
No output indicates success. To start and enable simultaneously:
systemctl enable --now nginx
Stopping Services
Stop running the service gracefully:
systemctl stop nginx
The service receives cleanup time before shutdown. For unresponsive services:
systemctl kill -s SIGKILL nginx
Restarting Services
Restart service to apply configuration changes:
systemctl restart nginx
Verify the configuration before restarting critical services to avoid disruption.
Reloading Configuration
Apply new settings without stopping the service:
systemctl reload nginx
Reloading maintains connections while applying new settings. Not all services support reload operations.
Enabling Services at Boot
Configure service for automatic startup:
systemctl enable nginx
Creates necessary systemd directory links without starting the service immediately. The enable command automatically runs daemon-reload.
Disabling Services at Boot
Prevent automatic boot startup:
systemctl disable nginx
Currently running services remain active. This only affects boot behavior.
Checking Service State
Verify boot configuration:
systemctl is-enabled nginx
Check active status:
systemctl is-active nginx
Check failure status:
systemctl is-failed nginx
These commands return simple yes/no responses, suitable for scripts and automation.
Listing Units
View all loaded services:
systemctl list-units --type=service
View all installed unit files regardless of status:
systemctl list-unit-files
Show only failed units:
systemctl --failed
Viewing Unit Files
Display complete configuration in use:
systemctl cat nginx
Shows the base unit file plus any overrides or drop-ins.
Editing Unit Files
Open the editor to modify the service:
systemctl edit nginx
Creates override files safely. For complete replacement:
systemctl edit --full nginx
systemd automatically reloads after saving changes.
Masking Services
Completely prevent service execution:
systemctl mask nginx
Masking links the unit file to /dev/null. Nothing can start it until unmasked:
systemctl unmask nginx
Use masking to guarantee service remains disabled.
Reloading systemd Configuration
Reload all unit files:
systemctl daemon-reload
Required after manually editing unit files. The systemctl edit command handles this automatically.
Quick Command Reference
| Command | Purpose |
|---|---|
| systemctl status SERVICE | Check service state and logs |
| systemctl start SERVICE | Start service now |
| systemctl stop SERVICE | Stop service |
| systemctl restart SERVICE | Restart service |
| systemctl reload SERVICE | Reload config without restart |
| systemctl enable SERVICE | Auto-start at boot |
| systemctl disable SERVICE | Prevent auto-start |
| systemctl enable --now SERVICE | Enable and start together |
| systemctl is-enabled SERVICE | Check boot status |
| systemctl is-active SERVICE | Check running status |
| systemctl is-failed SERVICE | Check failure status |
| systemctl list-units --type=service | List all services |
| systemctl --failed | Show failed units |
| systemctl daemon-reload | Reload unit files |
| systemctl edit SERVICE | Edit with overrides |
| systemctl cat SERVICE | View unit file |
| systemctl mask SERVICE | Prevent all starts |
| systemctl unmask SERVICE | Allow starts again |
Advanced Features
Systemd Timers
Timers replace cron jobs with better systemd integration. Implementation requires two files: a .timer unit for scheduling and a .service unit for task definition.
View all active timers and next run times:
systemctl list-timers
Timers provide superior logging and dependency management compared to traditional cron.
Custom Unit Files
Create custom services in /etc/systemd/system/. Basic template:
[Unit]
Description=My Custom Application
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/myapp
Restart=on-failure
User=appuser
WorkingDirectory=/opt/myapp
[Install]
WantedBy=multi-user.target
Load and start the new service:
systemctl daemon-reload
systemctl start myapp
systemctl enable myapp
Viewing Logs with journalctl
journalctl queries the systemd journal for detailed logs:
journalctl -u nginx
Follow logs in real-time:
journalctl -u nginx -f
Show recent entries only:
journalctl -u nginx -n 50
Filter by time:
journalctl -u nginx --since "1 hour ago"
Managing System State
Control server power states:
systemctl poweroff
systemctl reboot
systemctl suspend
systemctl hibernate
Troubleshooting Common Issues
Service Failures
Check service status first:
systemctl status service-name
Output includes exit codes: 0 indicates success, non-zero indicates errors (1 for general errors, 2 for command misuse, 126 for execution permission issues, 127 for command not found).
Common problems and solutions:
Configuration errors result from syntax issues. Validate with service-specific commands:
nginx -t
apachectl configtest
sshd -t
Missing dependencies occur when required services aren’t running. Check requirements:
systemctl list-dependencies service-name
Port conflicts happen when another process uses the port. Identify the process:
ss -tlnp | grep :80
netstat -tlnp | grep :80
Permission issues appear as “permission denied” errors. Verify file ownership matches the User directive:
ls -l /path/to/file
chown user:group /path/to/file
chmod 644 /path/to/file
Resource limits cause crashes from insufficient memory or CPU. Check resource usage in the status output:
systemctl status service-name
Restart Loops
Services that crash and restart repeatedly require underlying problem resolution. Check restart policy:
systemctl cat service-name
Review RestartSec and StartLimitBurst settings controlling restart frequency and attempt limits.
View detailed error logs:
journalctl -u service-name -p err
Resolve root cause before clearing failed state:
systemctl reset-failed service-name
systemctl start service-name
Unit File Changes Not Applied
After manual file edits, reload systemd:
systemctl daemon-reload
systemctl restart service-name
Verify active file location:
systemctl show -p FragmentPath service-name
Permission and SELinux Issues
Check file permissions:
ls -l /path/to/file
Correct ownership and permissions:
chown user:group /path/to/file
chmod 755 /path/to/executable
On SELinux-enabled systems, verify security contexts:
ls -Z /path/to/file
Restore default contexts:
restorecon -v /path/to/file
For permanent context changes:
semanage fcontext -a -t httpd_sys_content_t "/path/to/file"
restorecon -v /path/to/file
Dependency Errors
Services fail when starting before requirements are met. Verify dependencies:
systemctl list-dependencies service-name
Check for configuration problems:
systemd-analyze verify service-name.service
Finding All Failed Units
View all failed services:
systemctl --failed
Prioritize critical services. Single failures often cascade to multiple failures. Resolving root causes typically fixes multiple issues.
Reset all failures after repairs:
systemctl reset-failed
Conclusion
This guide covers essential systemctl functionality for managing Linux services. Core commands (status, start, stop, restart, enable, disable) handle daily operations. Unit file knowledge enables service customization and creation. Troubleshooting techniques provide quick problem diagnosis and resolution.
Key practices: use systemctl edit for safe modifications, check logs with journalctl during failures, verify configurations before restarting critical services, and run daemon-reload after manual edits. For comprehensive information, consult the man pages (man systemctl, man systemd) and official documentation at systemd.io.
