Understanding Services
A systemd service unit is a configuration file that describes how to start, stop, and supervise a process. Before you can manage services effectively, you need to understand what a unit file contains and what each directive does. This knowledge is also essential for writing your own service units for custom applications.
What is a service unit?
# View an existing service unit file
systemctl cat nginx.service
nginx.service unit file
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=mixed
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Service unit file structure
| Section | Purpose | Key directives |
|---|---|---|
| [Unit] | Metadata and dependencies | Description=, After=, Requires=, Wants= |
| [Service] | Process management | Type=, ExecStart=, Restart=, User=, WorkingDirectory= |
| [Install] | Enable/disable behavior | WantedBy=, RequiredBy=, Alias= |
# Show all properties of a service (including inherited defaults)
systemctl show nginx.service | grep -E "^(Type|ExecStart|Restart|User|WorkingDirectory)"
Service types
The Type= directive tells systemd how the process behaves at startup — specifically, when systemd should consider the service "ready."
| Type | When "ready"? | Use for |
|---|---|---|
| simple | When ExecStart process starts | Most modern services (default) |
| forking | When ExecStart process forks and parent exits | Traditional daemons (nginx, apache) |
| oneshot | After ExecStart process exits successfully | Scripts that run once (like rc.local) |
| notify | When process sends sd_notify("READY=1") | Services that support systemd notification (postfix, journald) |
| dbus | When process acquires a DBus name | DBus-activated services |
| idle | Like simple but delayed until other jobs finish | Services that should run after boot |
# Check what type a service uses
systemctl show sshd.service -p Type
Output
Type=notify
Where unit files live
# Unit file locations (in priority order, highest to lowest):
# /etc/systemd/system/ — Local overrides (your changes go here)
# /run/systemd/system/ — Runtime units (transient, cleared on reboot)
# /lib/systemd/system/ — Package-installed units (don't edit these)
# NEVER edit /lib/systemd/system/ — apt will overwrite your changes on upgrade
# ALWAYS put overrides in /etc/systemd/system/
# For partial overrides (change one directive without replacing the whole file):
systemctl edit nginx.service # Creates /etc/systemd/system/nginx.service.d/override.conf
# For complete replacement:
systemctl edit --full nginx.service # Copies to /etc/systemd/system/nginx.service
System vs user services
# System services: run as root or a specified user, managed by PID 1
# User services: run in user session context (no root)
# System service (requires root or sudo)
sudo systemctl start nginx
sudo systemctl status nginx
# User service (for your own user session)
# Unit files in ~/.config/systemd/user/
systemctl --user start myapp
systemctl --user status myapp
systemctl --user enable myapp
# Enable user services to run after logout (for CI runners, etc.)
sudo loginctl enable-linger username
Conclusion
Every systemd service is described by a unit file with three sections: [Unit] for metadata and dependencies, [Service] for how to run the process, and [Install] for enable/disable behavior. The Type= directive is critical — using the wrong type (e.g., simple for a forking daemon) causes systemd to report success before the service is actually ready. Always put your custom unit files and overrides in /etc/systemd/system/ — never edit files in /lib/systemd/system/ because package upgrades will overwrite them.
FAQ
Is Understanding Services important for Ubuntu administrators?+
Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.
Should I practice this on a live server?+
Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.
What should I do after reading this article?+
Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.
Need help with Ubuntu administration?
Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.
Hire Me for Support