Best Practices

Systemd unit files are the foundation of service management in Linux systems. They define how services, sockets, timers, and other units are configured, launched, and integrated into the systemd ecosystem. Mastery of their syntax and best practices ensures reliability, security, and maintainability. This section explores the structure of unit files, key best practices, and common pitfalls to avoid when authoring them.

Core Syntax Structure¶

A systemd unit file is a plaintext configuration file divided into sections and key-value pairs. Each unit file has a unique name (e.g., nginx.service) and is stored in /etc/systemd/system/ or /lib/systemd/system/.

Key Sections¶

[Unit]: Metadata and dependencies (e.g., Description, After, Requires).
[Service]: Process control (e.g., ExecStart, Restart, User).
[Install]: Installation directives (e.g., WantedBy, Alias).
[Scope] or [Slice]: For managing resource limits or grouping units.

Example: Basic Service Unit File¶

[Unit]
Description=Example Service
After=network.target

[Service]
ExecStart=/usr/bin/example-service
Restart=always
User=example-user
Group=example-group

[Install]
WantedBy=multi-user.target

Syntax Rules¶

Keys are case-sensitive (e.g., User vs. user).
Values must be quoted if they contain spaces.
Use [Unit] for dependencies and [Service] for process control.

Best Practices for Maintainability¶

Use Descriptive Names and Comments
Avoid ambiguous names like service1. Use nginx.service for clarity. Add inline comments (e.g., # Ensure network is up before starting).
Avoid Redundant Dependencies
Use Requires and After to enforce ordering, but avoid over-specifying. For example, After=network.target ensures the service starts after the network is ready.
Leverage Systemd Features
Replace custom scripts with systemd-native features like:
Sockets for listening on ports (example.socket).
Timers for periodic tasks (example.timer).
Mount Units for automounting filesystems.
Use Environment Files
Store configuration variables in /etc/default/ or /etc/systemd/system/example.service.d/override.conf using EnvironmentFile.
Minimize ExecStart Complexity
Avoid chaining commands in ExecStart. Use separate units or scripts for complex logic.

Security and Resource Management¶

Drop Privileges
Set User and Group to non-root accounts. Use PrivateTmp=true to isolate temporary files.
Restrict Capabilities
Use AmbientCapabilities= to limit privileges (e.g., AmbientCapabilities=CAP_NET_BIND_SERVICE).
Enable Protection Features
Add ProtectSystem=strict to prevent file system modifications. Use ProtectHome=true to block access to user home directories.
Set Resource Limits
Control memory and CPU usage with:
```
LimitCPU=50
LimitMEM=512M
```
Adjust values based on system requirements.
Use Secure Defaults
Enable PrivateDevices=true to isolate hardware devices and NoNewPrivileges=true to prevent privilege escalation.

Common Pitfalls to Avoid¶

Forgetting to Reload
After editing a unit file, run systemctl daemon-reload to apply changes.
Using Absolute Paths
Avoid hardcoding paths like /usr/bin/example-service. Use relative paths or environment variables.
Misconfigured Restart Policies
Restart=always ensures the service restarts on failure, but Restart=on-failure is often sufficient.
Incorrect Dependencies
Missing After or Requires can cause services to start in the wrong order, leading to failures.
Not Testing Changes
Use systemctl start example.service and journalctl -u example.service to debug issues.

Key takeaways¶

Use clear, descriptive names and comments for readability.
Leverage systemd-native features (sockets, timers) instead of custom scripts.
Prioritize security by dropping privileges and restricting capabilities.
Avoid redundancy in dependencies and use daemon-reload after edits.
Test changes with systemctl and journalctl to ensure reliability.