systemd Guide: Services, Timers, Logs and Troubleshooting
systemd is the service manager used by many modern Linux distributions. If you manage servers, you will use it to start services, enable services at boot, inspect logs, create timers and diagnose failures.
What is systemd?
systemd is an init and service management system. It starts the system, manages services, tracks dependencies, captures logs through the journal, and can run scheduled tasks through timers.
Services
Manage daemons like nginx, sshd, mariadb and custom scripts.
Timers
Schedule tasks like backups, cleanup scripts and health checks.
Logs
Use journalctl to inspect logs for services and boot sessions.
systemctl basics
| Task | Command |
|---|---|
| Check service status | systemctl status nginx |
| Start a service | sudo systemctl start nginx |
| Stop a service | sudo systemctl stop nginx |
| Restart a service | sudo systemctl restart nginx |
| Reload config | sudo systemctl reload nginx |
| Enable at boot | sudo systemctl enable nginx |
| Show failed units | systemctl --failed |
● nginx.service - A high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
Active: active (running) since Sun 2026-05-03 10:22:41 BST; 2h ago
Main PID: 1184 (nginx)
Tasks: 3
Memory: 12.4Msystemctl enable vs start
start runs the service now. enable configures it to start on boot. If you want both, use enable --now.
sudo systemctl enable --now nginxenabledjournalctl examples
| Task | Command |
|---|---|
| Logs for one service | journalctl -u nginx |
| Latest 50 lines | journalctl -u nginx -n 50 |
| Follow live logs | journalctl -u nginx -f |
| Logs since today | journalctl --since today |
| Logs from current boot | journalctl -b |
| Kernel messages | journalctl -k |
May 03 12:20:12 server sshd[2410]: Accepted publickey for admin from 203.0.113.10 port 51122
May 03 12:20:12 server sshd[2410]: pam_unix(sshd:session): session opened for user admin
May 03 12:41:03 server sshd[2511]: Failed password for invalid user test from 198.51.100.22Basic systemd service unit
Custom services are commonly stored in /etc/systemd/system/. Here is a simple oneshot unit that runs a script.
[Unit]
Description=Run website backup
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/website-backup.sh
[Install]
WantedBy=multi-user.targetAfter creating or editing a unit file, reload systemd:
sudo systemctl daemon-reloadsystemd timers instead of cron
Timers can replace many cron jobs. They are easy to inspect with systemctl list-timers and they integrate with the journal.
[Unit]
Description=Run backup daily
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
Unit=website-backup.service
[Install]
WantedBy=timers.targetsudo systemctl enable --now website-backup.timer
systemctl list-timers website-backup.timerHow to troubleshoot a failed service
- Check status:
systemctl status service-name - Read logs:
journalctl -u service-name -n 100 --no-pager - Check failed units:
systemctl --failed - Validate the service config, if the application has a config test command.
- Reload systemd after editing unit files:
systemctl daemon-reload - Restart the service and watch logs live.
UNIT LOAD ACTIVE SUB DESCRIPTION
backup.service loaded failed failed Backup example.com website with rsync
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.Useful systemd examples
Reload a service after a config change
sudo nginx -t
sudo systemctl reload nginxRestart and follow logs
sudo systemctl restart nginx
sudo journalctl -u nginx -fShow unit file location
systemctl cat nginxCheck boot time blame
systemd-analyze blameMore Linux admin practice
A practical systemd troubleshooting order
When a service fails, check status first, then logs, then the unit file. This keeps the investigation clean and avoids changing things blindly.
# 1. Check current state
systemctl status nginx
# 2. Read recent service logs
journalctl -u nginx -n 80 --no-pager
# 3. Follow logs live while restarting
journalctl -u nginx -f
# 4. Check the unit file
systemctl cat nginx
# 5. Reload systemd after editing a unit
systemctl daemon-reloadActive: failed (Result: exit-code)
Main PID: 1842 (code=exited, status=1/FAILURE)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)start vs enable vs reload
| Command | Meaning |
|---|---|
systemctl start nginx | Start the service now. |
systemctl enable nginx | Start the service automatically at boot. |
systemctl restart nginx | Stop and start the service. |
systemctl reload nginx | Reload configuration without a full restart, if supported. |
systemctl daemon-reload | Reload unit files after editing systemd configuration. |
Frequently Asked Questions
What is the difference between systemctl start and enable?
start runs a service now. enable configures it to start automatically at boot.
When should I run systemctl daemon-reload?
Run daemon-reload after creating or editing a unit file so systemd reloads the unit definition.
How do I view logs for one service?
Use journalctl -u service-name, for example journalctl -u nginx -n 100 --no-pager.
Why does systemctl show active but the site is still down?
The service may be running but misconfigured, listening on the wrong port, blocked by firewall rules or failing at the application layer.