The big idea
A daemon is a long-lived program that runs in the background, waking up only when some event—a packet on a socket, the system clock striking midnight, or a kernel notification—demands work. Unlike interactive processes, daemons normally have no controlling terminal, start at boot, and keep the machine’s services humming: logging, scheduling, name resolution, web delivery, and much more. (Wikipedia)
1 What makes a process a daemon?
| Characteristic | Why it matters |
|---|---|
| Detachment from a TTY | Prevents stray SIGINT/SIGHUP from a user terminal from killing the service. |
Parent is init or systemd | Ensures the process is reaped and monitored by the OS. |
| Runs at boot or on-demand | Guarantees availability before clients arrive. |
Often named *d | Conventional suffix (sshd, syslogd, crond) signals its role. |
Under classic System V init, a program calls fork(), setsid(), changes directory to /, adjusts umask, closes file descriptors, and forks again so the grand-child is not a session leader—eliminating the chance of ever reacquiring a terminal (Wikipedia, 0xjet.github.io, Stack Overflow).
Modern hosts delegate that plumbing to service managers (systemd, launchd, OpenRC) which spawn the daemon in a clean namespace and supervise it.
2 Lifecycle and supervision
| Stage | Traditional init scripts | Modern service managers |
|---|---|---|
| Startup | Shell script in /etc/rc.d forks the daemon | Declarative unit file specifies binary, dependencies, sandbox |
| Monitoring | None—admin must notice crashes | Automatic restart / rate-limiting (Restart=on-failure, StartLimit*) (Mattias Geniar) |
| Logging | Daemon writes to /var/log/*.log | Stdout/stderr captured by journald; structured metadata |
| Shutdown | Sends SIGTERM; waits fixed time | Ordered stop graph; timeouts + SIGKILL if needed |
Because supervision is built-in, a daemon that segfaults at 02:00 is quietly restarted before the help-desk phone rings.
3 Function, scalability, reliability, security — design lenses
| Lens | Engineering techniques | Illustrative daemon(s) |
|---|---|---|
| Function | Listen on well-known port or timer; parse requests; execute core logic. | sshd (remote shell), crond (job scheduler), cupsd (print spooling). |
| Scalability | Prefork workers (httpd), thread pools (postgres), event loops (nginx); sharding across hosts. | nginx spawns worker_processes equal to CPU cores; mysqld clusters with Galera. |
| Reliability | Supervision, health checks, graceful reload (SIGHUP), hot spare replicas, persistent state journals. | systemd-resolved switches to fallback upstreams; sshd forks per-connection so one hung session can’t freeze others. |
| Security | Drop privileges (setuid(nobody)), chroot/RootDirectory=, Linux capabilities, seccomp filters, mandatory TLS. | bind9 runs as non-root in a jail; systemd-networkd uses ProtectSystem=strict. |
4 Daemon patterns in practice
| Category | Core purpose | Typical communication | Example daemons |
|---|---|---|---|
| Network services | Answer remote clients | TCP/UDP sockets | sshd, httpd, named, dhcpd |
| System services | Manage local resources | Netlink, D-Bus, UNIX sockets | udevd, NetworkManager, systemd-logind |
| Schedulers | Run jobs at specific times | Internal queue, fork/exec | crond, atd |
| Monitoring/telemetry | Collect & ship metrics | gRPC, HTTP, custom proto | prometheus-node_exporter, collectd |
All of these obey the daemon contract: start early, stay out of the user’s way, and respond on demand.
5 Daemons, services and servers—clearing the terminology
- Daemon – the process that lives in the background.
- Service – in
systemd, the unit definition that controls how the daemon is run. - Server – a role: any daemon that offers a network service (every server is a daemon, but not vice-versa). (Wikipedia)
Windows speaks of services rather than daemons, but the contract is identical: a non-interactive, boot-time process managed by the Service Control Manager.
6 Modern evolution
- Socket activation reduces idle memory: the OS listens, and the daemon starts only when the first packet arrives.
- Containers package one daemon per image, supervised by the orchestrator instead of
init. - User daemons (e.g., per-login
dbus-daemon --session) obey the same rules but sit in a user slice rather than PID 1’s domain.
Take-away
A daemon is the silent workhorse of every Unix-style system: disciplined detachment plus robust supervision makes it possible for background services to run reliably, at scale, and securely for months—or years—without human intervention.