Background processes that power Linux systems: understand what daemons are, how systemd replaced SysVinit, master systemctl for service management, dissect unit files, query logs with journalctl, and automate tasks with cron.
Slide 1 — What Is a Daemon?
A Background Process That Provides System Services
A daemon is a long-running background process that starts at boot and provides services either to the system or to network clients. Daemons have no controlling terminal — they run detached from any user session. The name comes from Unix mythology: a helper that runs in the background doing work.
Identifying characteristic: daemon names conventionally end in 'd'. sshd handles SSH connections, httpd is the Apache web server, crond runs scheduled tasks, rsyslogd collects system logs.
A daemon's lifecycle: start at boot (or on demand), run continuously waiting for requests or events, restart automatically if it crashes, and stop gracefully on shutdown.
Web server daemons. Apache httpd and Nginx serve HTTP/HTTPS requests. Handle static files, reverse proxy, and dynamic content.
crond
Cron daemon — reads crontab files and executes scheduled tasks at specified times. The timer service for automation.
rsyslogd
System logging daemon. Collects log messages from the kernel and applications, routes them to files in /var/log/. Critical for auditing and incident response.
MySQL/MariaDB database server. Handles database queries, manages data files, enforces access control. Data-layer foundation for most web applications.
dockerd
Docker daemon. Manages container lifecycle — build, run, stop, delete containers. Exposes the Docker API that the docker CLI communicates with.
firewalld
Dynamic firewall daemon. Manages iptables/nftables rules for network packet filtering. Provides zones and services abstraction over raw firewall rules.
Slide 3 — systemd: The Modern Init System
SysVinit (Legacy)
Sequential startup — scripts ran one after another, even when they had no dependencies on each other. Slow boot times. Scripts in /etc/init.d/. Runlevels (0-6) controlled what started. Still used on some minimal systems.
systemd (Modern)
Parallel startup — services with no dependencies start simultaneously. Much faster boot. Unit files in /etc/systemd/system/. Targets replace runlevels. Socket and D-Bus activation. Dependency tracking. Integrated logging (journald).
systemd Unit Types
Service units (.service) — define how to start a daemon (most common type you'll work with).
Target units (.target) — group of units, like runlevels. multi-user.target replaces runlevel 3, graphical.target replaces runlevel 5.
Timer units (.timer) — schedule service activation (systemd's cron replacement).
Socket units (.socket) — activate a service when a connection arrives on a socket (on-demand activation).
Mount units (.mount) — manage filesystem mounts.
Slide 4 — Anatomy of a systemd Unit File
# /etc/systemd/system/mywebapp.service[Unit]Description=My Web ApplicationAfter=network.target mysql.service# Start after theseRequires=mysql.service# Hard dependency[Service]Type=simple# Process stays in foregroundUser=www-data# Run as this user (not root!)WorkingDirectory=/opt/myappExecStart=/usr/bin/python3 app.py# Command to startExecReload=/bin/kill -HUP $MAINPID# Command for reloadRestart=always# Restart if crashesRestartSec=5# Wait 5s before restartStandardOutput=journal# Log stdout to journaldStandardError=journal[Install]WantedBy=multi-user.target# Enable at this target
Slide 5 — systemctl: Managing Services
systemctl start nginx
Start service immediately (does not persist across reboot)
systemctl stop nginx
Stop service immediately
systemctl restart nginx
Stop then start (brief downtime)
systemctl reload nginx
Reload config without stopping (if supported)
systemctl enable nginx
Auto-start at boot (creates symlink to target)
systemctl disable nginx
Remove auto-start at boot
systemctl status nginx
Show running status, recent log entries, PID, memory
systemctl list-units --type=service
List all active service units
# After writing a new unit file:
$ sudo systemctl daemon-reload # Reload systemd config (required!)
$ sudo systemctl enable --now nginx # Enable AND start in one command# journalctl — query the systemd journal
$ journalctl -u nginx # Logs for nginx service
$ journalctl -u nginx -f # Follow (tail -f equivalent)
$ journalctl -u nginx --since "1 hour ago"
$ journalctl -p err # Show only errors
$ journalctl -b # Logs from current boot
$ journalctl -b -1 # Logs from previous boot
$ journalctl --disk-usage # How much space logs use
Slide 6 — Task Automation with Cron
Scheduling Commands to Run Automatically
Cron is the traditional job scheduler daemon. You define tasks in a crontab (cron table) file. Each line specifies when to run a command using five time fields: minute, hour, day of month, month, and day of week.
Crontab field positions:
*Minute 0-59
*Hour 0-23
*Day/Month 1-31
*Month 1-12
*Day/Week 0-7 (Sun=0)
commandCommand to execute
# Edit your crontab
$ crontab -e # Open in editor (creates if needed)
$ crontab -l # List current crontab
$ crontab -r # Remove crontab (WARNING: no confirmation)# Crontab examples
0 2 * * * /opt/scripts/backup.sh # Daily at 2:00 AM
*/5 * * * * /usr/local/bin/monitor.py # Every 5 minutes
0 9 * * 1 /scripts/weekly-report.sh # Monday at 9:00 AM
30 4 1 * * /scripts/monthly-cleanup.sh # 1st of month, 4:30 AM
@reboot /opt/startup.sh # Run once at system boot
@daily /opt/daily.sh # Shorthand for 0 0 * * *# System-wide cron (root)# /etc/cron.d/ — drop-in crontab files# /etc/cron.daily/ — scripts run daily# /etc/cron.hourly/ — scripts run hourly
SECURITY: CRON AS AN ATTACKER'S TOOL
Cron is one of the most common persistence mechanisms used by attackers after gaining initial access. A malicious crontab entry ensures their backdoor or reverse shell is restarted regularly. When investigating a compromised system, always check: crontab -l (current user), sudo crontab -l -u root (root's crontab), cat /etc/crontab, and all files in /etc/cron.d/, /etc/cron.daily/, etc. Also check /var/spool/cron/crontabs/ for all user crontabs. Systemd timers can serve the same persistence purpose — audit both. Finding an unexpected cron job running from /tmp/ or /dev/shm/ is a significant red flag.
Presentation Complete
Mark complete to save your progress and unlock the Chapter 5 quiz.
Progress saved. Head to the quiz to test your knowledge.