2026
What is a Daemon?
Background processes that run without a terminal, survive after you log out and power most of what Linux does. Here is what they actually are.
Most processes on a Linux system have a direct relationship with a terminal. You open a shell, run a command, the command does its work and returns control when it is done. You can see its output, interrupt it with Ctrl+C and know exactly when it finishes.
A daemon is different. It runs in the background with no terminal attached. Nobody is sitting there waiting for it to finish. It just runs, responding to events or requests as they arrive, for as long as the system is up.
You interact with daemons constantly without thinking about it. Every SSH connection goes through sshd. Every web request is handled by something like nginx or apache2. When Kubernetes schedules a pod onto a node, the kubelet picks that up and makes it happen. All of these are daemons.
Where the name comes from
The term comes from the 1960s. Programmers at MIT building one of the first time-sharing operating systems needed a word for background processes that sat waiting and performed work whenever conditions called for it.
They borrowed from Maxwell's demon, a thought experiment in physics about an entity that watches molecules and acts on them without being acted upon. The spelling shifted from demon to daemon specifically to avoid any sinister connotation. Despite the name, most daemons spend their time doing quite ordinary things like serving files or writing logs.
What actually makes a process a daemon
There is no special system call that turns a process into a daemon. It is a set of properties that, taken together, describe a long-running background process with no user attached to it.
No controlling terminal
A daemon has no tty attached. It is not waiting for keyboard input. If you look at it in the process table, the TTY column shows a question mark.
Runs as a child of init
Its parent process is typically pid 1, which is systemd on modern systems. This means it survives even after the shell that started it has exited.
Stays alive independently
It does not exit when its work is done. It waits. An SSH daemon sits there doing nothing until a connection arrives. A web server does nothing until a request comes in.
Redirected I/O
Standard input, output and error are not connected to a terminal. They go to the journal, a log file or /dev/null depending on how the daemon is configured.
Daemons you already know
By convention, daemon names end in the letter d. Once you know this, you start noticing them everywhere.
sshdnginxcronsystemd-journaldNetworkManagerdockerdkubeletSpotting daemons on a running system
Run ps aux and look at the TTY column. Regular processes show a terminal name there like pts/0. Daemons show ? because they have no controlling terminal.
USER PID TTY COMMANDroot 612 ? /usr/sbin/sshd -Dwww-data 891 ? nginx: worker processuser 1423 pts/0 bashuser 1891 pts/0 ps auxThe first two have no terminal. The last two are attached to your current shell session. That single column tells you a lot about how a process is meant to behave.
How daemons were traditionally created
Before systemd, turning a process into a proper daemon was something the program had to do itself. The classic sequence looked like this:
fork()The process creates a child copy of itself. The parent exits so the shell gets its prompt back.
setsid()The child creates a new session, severing its connection to the controlling terminal.
chdir("/")Change the working directory to the root so the daemon does not hold a reference to any mounted filesystem.
Close file descriptorsStdin, stdout and stderr are closed or redirected to /dev/null so nothing unexpected reads from or writes to a terminal.
Every daemon had to implement this boilerplate. Some got it slightly wrong. Debugging was painful because log output went nowhere useful. Dependency ordering between services was handled with numbered init scripts and a lot of manual care.
What systemd changed
systemd took the daemonisation burden away from the program itself. When you write a service unit with Type=simple, your process just runs in the foreground. It does not fork, it does not call setsid(), it does not redirect its own file descriptors. systemd handles all of that.
Before systemd
Program forks itself into the background
Closes its own terminal
Writes a PID file for tracking
Redirects output to a log file
With systemd
Program runs in the foreground
systemd detaches it from the terminal
systemd tracks the PID directly
stdout and stderr go to the journal
This is why modern service files look so simple. The complexity is still there. It just moved into systemd where it can be handled consistently across every service on the system rather than reimplemented by each one.
They are everywhere
On a typical Linux server, the majority of running processes are daemons. Run systemctl list-units --type=service --state=running and you will see exactly which ones systemd is currently managing. Most of them have been sitting there since boot, doing nothing, waiting for something to do.
That is the point. A well-behaved daemon uses almost no resources when idle. It wakes up, does its work and goes back to waiting. Understanding what a daemon is makes the whole picture of how a Linux system operates much clearer from why services survive after you close your SSH session to why systemd exists in the first place.