More Than Just Services
While .service files are the most common unit type, systemd manages a broader set of system resources. Understanding the full set helps you recognize when systemd is the right tool for a job that you might otherwise solve with a shell script or cron job.
1. Service Units (.service)
The core unit type. Describes a long-running process (daemon) or a one-shot task. Examples: nginx.service, postgresql.service, sshd.service.
2. Timer Units (.timer)
The modern, superior replacement for cron jobs. A .timer unit triggers a corresponding .service unit on a schedule. The service does the actual work; the timer only handles scheduling.
Advantages over cron:
- Missed runs are caught up automatically if the system was off (Persistent=true).
- Logs appear in the journal alongside the service logs — no more hunting through /var/log/cron.
- You can test the service independently of the timer by running systemctl start myservice.service directly.
3. Mount Units (.mount)
Describes a filesystem mount point. The unit name must match the mount path — for example, /home/data becomes home-data.mount. Systemd automatically generates mount units from /etc/fstab entries at boot, so you rarely write these by hand. However, they appear in systemctl list-units and can be managed like any other unit.
4. Socket Units (.socket)
Enables socket activation: systemd listens on a network port or Unix socket, and only starts the corresponding service when the first connection arrives. This reduces memory usage (services don't run until needed) and enables faster boot times (the socket is ready immediately, even before the service starts). SSH and D-Bus use this pattern.
5. Path Units (.path)
Watches a file or directory for changes and activates a service when a change is detected. Useful for processing uploaded files or triggering builds when source code changes.
6. Target Units (.target)
Groups of units. Covered in detail in the dedicated Targets lesson.