3.4.2. Service Configurations and Common Daemons

💡 First Principle: A daemon is a background process that provides a service. On Linux, daemons are managed by systemd. Their configuration lives in /etc/ in text files. The pattern is always the same: install the package → edit the config file → reload/restart the service → verify it's running and set to start at boot.

Common Services Tested on XK0-006:

Basic service lifecycle (applies to all):

systemctl start nginx            # Start now
systemctl stop nginx             # Stop now
systemctl restart nginx          # Stop then start (drops connections)
systemctl reload nginx           # Reload config without dropping connections (if supported)
systemctl enable nginx           # Start at boot
systemctl disable nginx          # Don't start at boot
systemctl enable --now nginx     # Enable AND start immediately (one-step)
systemctl status nginx           # Current state, recent logs

Sandboxed Applications: Applications distributed outside traditional package managers (AppImage, Snap, Flatpak) run in sandboxed environments with restricted access to the host filesystem. The exam covers these conceptually:

• Snap: Canonical's format; packages include all dependencies; /snap/bin/ in PATH
• Flatpak: Cross-distro; portal-based permissions; used heavily on desktop Linux
• AppImage: Single executable; no install needed; no sandbox by default

⚠️ Exam Trap: systemctl reload is NOT available for all services — only those that implement the reload signal (usually SIGHUP). If a service doesn't support reload, systemctl reload may fail silently or with an error. For services that don't support live config reload (like some DHCP servers), you must restart, which briefly interrupts service.

Reflection Question: You install nginx, edit its config, and run systemctl start nginx. The service starts. After a server reboot the next morning, nginx is not running. What command should you have run, and what is the concise one-liner that handles both tasks?