A daemon is a long-running background process on Unix-like systems that runs without a controlling terminal, usually starts at boot and waits for events, requests or scheduled times in order to provide a service. On servers, daemons do most of the real work: sshd accepts remote logins, crond runs scheduled jobs, and web, database and mail servers all run as daemons.
The term comes from MIT’s Project MAC in the 1960s and alludes to Maxwell’s demon, an imagined helper that works unseen in the background. By convention, daemon program names often end in the letter d, as in systemd, httpd or named. On Windows, the equivalent concept is called a service.
What makes a process a daemon
A daemon is defined by how it runs, not by what it does. Any program becomes a daemon when it is detached from user sessions and kept alive independently, and several properties distinguish it from an ordinary interactive process.
| Property | Interactive process | Daemon |
|---|---|---|
| Controlling terminal | Attached to a shell or terminal | None |
| Lifetime | Ends when the task or session ends | Runs until stopped or the system shuts down |
| Parent process | Usually the user’s shell | The init system, PID 1 on Linux |
| Input and output | Keyboard and screen | Sockets, files, logs or the system journal |
| User account | The logged-in user | Often a dedicated unprivileged service account |
Because nobody watches a daemon’s screen, it must report through logs and be controlled through signals or a management interface. By long convention, SIGTERM asks a daemon to shut down cleanly and SIGHUP asks many daemons to reload their configuration without exiting.
Classic daemonization with the double fork
Traditional System V-style daemons detach themselves through a fixed sequence of system calls, known as daemonization or the double fork. Each step removes one tie to the session that launched the program.
- Fork and exit the parent, so the shell regains control and the child is not a process group leader.
- Call setsid() to start a new session with no controlling terminal.
- Fork a second time so the daemon can never reacquire a terminal.
- Change the working directory to
/so the daemon does not keep a file system mounted. - Reset the file mode mask with
umask(0)or a defined value. - Close inherited file descriptors and redirect standard input, output and error to
/dev/null. - Write the process ID to a PID file, such as
/var/run/name.pid, so scripts can signal it later.
Many network daemons also start as root to bind privileged ports below 1024, then drop to an unprivileged user before handling any requests. This privilege separation limits the damage if the daemon is compromised.
Daemons under modern service managers
Current Linux distributions run daemons under systemd, which handles detaching, logging and restarting itself. A modern daemon should therefore stay in the foreground and write logs to standard output, letting the service manager do the rest. The Type= setting in a unit file tells systemd how the daemon signals that it has started.
| Type | Readiness signal | Suitable for |
|---|---|---|
| simple | Considered started immediately after launch | Foreground programs with no readiness signal |
| exec | Started once the binary has been executed | Same as simple, with earlier error detection |
| forking | Parent process exits after the double fork | Legacy daemons that daemonize themselves |
| notify | Daemon sends READY=1 through sd_notify | Daemons that need time to initialize |
| oneshot | Main process exits after finishing its task | Setup jobs rather than true daemons |
Other platforms use comparable managers: launchd on macOS, the Service Control Manager on Windows, and lightweight supervisors such as runit or s6. In containers, the daemon usually runs as the main process of the container, with the container runtime acting as its supervisor.
Typical server daemons and their roles
Most services on a server map to one daemon, sometimes with a master process and worker processes beneath it. The table lists daemons that administrators encounter most often.
| Daemon | Service provided | Typical trigger |
|---|---|---|
| sshd | Encrypted remote login | Incoming connection on port 22 |
| crond | Scheduled job execution | Time-based schedule |
| nginx or httpd | Web serving | HTTP requests on ports 80 and 443 |
| mysqld or mariadbd | Database server | Client queries over TCP or a socket |
| rsyslogd or journald | Log collection | Log messages from other processes |
| chronyd | Clock synchronization | Periodic time source polling |
Common mistakes when running daemons
Problems with daemons usually appear only after deployment, because they occur without a visible terminal and often at unattended hours.
- Double daemonizing: a program that forks itself under a
simpleunit makes systemd believe it has exited, which causes restart loops or orphaned processes. - Stale PID files: after a crash, a leftover PID file can point to an unrelated process that happens to reuse the same process ID.
- Running as root unnecessarily: a compromised root daemon gives an attacker full control of the server.
- Unbounded logs: a daemon writing its own log files without rotation can fill the disk and stop other services.
- No supervision: a daemon started manually with nohup is not restarted after a crash, so use a service manager with a restart policy.
Explained without jargon
A daemon is a program that works quietly behind the scenes on a server. Nobody sits in front of it, and it has no window or screen; it simply waits for something to do, such as a visitor opening a web page or a scheduled task coming due.
It is like the night staff in a hotel: guests rarely see them, but they keep the building running around the clock. Most of what a server does for its users is handled by daemons.
A typical use case
A developer writes a small program that collects sensor readings every 10 seconds and forwards them to a database. Started from an SSH session, the program stops as soon as the developer logs out, because it is tied to that terminal.
The developer turns it into a proper daemon with a systemd unit: Type=simple, a dedicated unprivileged user, Restart=on-failure with a 5-second delay and logging to standard output. The service is enabled to start automatically at boot.
Over the next month, the collector crashes twice when the database is briefly unreachable. Each time, systemd restarts it within seconds, the journal records the error for later analysis and no readings are lost beyond the short outage windows.