Why Is It Called a Daemon? The Odd History of Background Processes

Run ps aux on almost any Linux server and you'll see a list of programs ending in "d": sshd, crond, systemd, journald, udevd. On a Mac, there's launchd. That "d" stands for daemon — a program that runs in the background, waiting to do its job without anyone watching.

It's a strange word to find in an operating system. It isn't a typo for "demon," it isn't an acronym, and it has nothing to do with anything evil. It comes from a physics thought experiment.

The short answer

The term was coined in the 1960s by programmers at MIT's Project MAC, the team working on some of the earliest time-sharing systems. They named their background programs after Maxwell's demon, a thought experiment from the 1860s by physicist James Clerk Maxwell.

Maxwell imagined a tiny being stationed at a door between two chambers of gas. It watches the molecules and lets fast ones through one way and slow ones through the other — quietly sorting the system without anyone telling it to. Physicists argued about that little demon for a century.

Fernando Corbató, who led the MIT group, later explained that their use of "daemon" was inspired by Maxwell's demon: a helper working tirelessly in the background. One of their first was a program that automatically backed up the file system to tape — exactly the kind of job nobody wants to do by hand.

Why "daemon" and not "demon"

"Daemon" is an older spelling that goes back to the Greek daimon — not a demon in the horror-movie sense, but a guiding spirit, something between a god and a person that worked behind the scenes in human affairs. Neither good nor evil, just busy.

That fits a background process almost too well. And the old spelling gave programmers a way to signal they meant the classical idea, not the scary one.

The acronym myth

You'll sometimes see "daemon" explained as Disk And Execution MONitor. It's a fun backronym, but it was invented after the fact. The word came first, and the MIT folks were explicit about where they got it.

Unix inherited the term from that same lineage, and the BSD branch of Unix even adopted a cartoon daemon as its mascot — a cheerful little red figure with sneakers and a trident.

What actually makes a process a daemon

A daemon is just an ordinary program arranged so it can run on its own. The traditional checklist looked like this:

1. Fork and let the parent exit. The program starts a copy of itself, then the original quits. Your shell sees the command finish and gives you your prompt back, while the copy keeps running.
2. Detach from the terminal. The program calls setsid() to start a new session with no controlling terminal. Now closing your terminal window or logging out won't kill it.
3. Fork again (often). A second fork guarantees the process can never accidentally grab a terminal again.
4. Get out of the way. Change the working directory to / so it doesn't keep some mounted drive busy, and reset file permission defaults.
5. Close or redirect the standard streams. A daemon has no one to talk to, so its standard input, output, and error (file descriptors 0, 1, and 2) get closed or pointed at /dev/null.

You can spot the result in ps:

$ ps -ef | grep sshd
root       812     1  0 09:14 ?        00:00:00 sshd: /usr/sbin/sshd -D

Two clues. The parent process ID is 1, the system's first process — either the daemon's original parent exited and PID 1 adopted it, or (on modern systems, more on that below) PID 1 started it directly. And the terminal column shows ?, meaning no controlling terminal. Nobody's at the keyboard for this one.

How it works today

Here's the twist: on a modern Linux system, most daemons don't do any of that anymore.

Service managers like systemd on Linux and launchd on macOS now handle the background part themselves. A modern daemon is often written to just run normally in the foreground and print its logs to standard output. systemd starts it, captures those logs, restarts it if it crashes, and keeps track of it — no double-forking required. systemd's own documentation calls these "new-style daemons" and recommends them over the old ritual.

So the old checklist is mostly history now, though you'll still run into it in older software and in shell tricks like nohup and &, which do a rough version of the same job.

Where the word gets fuzzy

• Not everything ending in "d" is a daemon, and not every daemon ends in "d." It's a naming habit, not a rule. Plenty of background services have ordinary names.
• Windows calls them "services." Same idea, different word, different management tools.
• "Background process" isn't the same thing. Running sleep 100 & in your shell puts a job in the background, but it's still tied to your terminal session. Log out and it may die with you. A daemon is built to outlive whoever started it.

Why it's worth knowing

Knowing what a daemon is makes servers a lot less mysterious. That list of "d" programs in ps stops being noise — it's the cast of background helpers keeping the machine running: sshd waiting for logins, crond watching the clock, journald collecting logs.

And honestly, I like that one of the most practical parts of computing is named after a physics thought experiment and an ancient Greek idea of helpful spirits. Somewhere in the 1960s, a group of programmers decided the work happening quietly in the background deserved a good name — and it stuck for sixty years.