Fundamentals 8 min read

Why Linux Daemons End with 'd': From Maxwell's Demon to systemd

This article traces the 'd' suffix in Linux daemon names like sshd and systemd to its 1963 MIT origin, where Fernando Corbató's team borrowed 'daemon' from Maxwell's Demon in physics, explaining the Greek spelling, Unix adoption, the fork() pun, and the later backronym 'Disk And Execution MONitor'.

ITPUB
ITPUB
ITPUB
Why Linux Daemons End with 'd': From Maxwell's Demon to systemd

The Origin of the 'd' Suffix

When you list processes on Linux, you see names like sshd, httpd, mysqld, dockerd, crond, and systemd — all ending with the letter d. This d stands for daemon, pronounced /ˈdiːmən/, identical to the English word demon. The term refers to background processes that run without direct user interaction.

From Maxwell's Demon to MIT's CTSS

The name originated at MIT's Project MAC in 1963. Fernando Corbató (later a Turing Award winner) led development of the Compatible Time-Sharing System (CTSS) on an IBM 7094. Before CTSS, computers ran batch jobs; CTSS introduced time-sharing so dozens of researchers could work simultaneously via teletypes. Disk space was tiny, so modified files had to be backed up to tape regularly. Manual backup was error-prone, so Corbató's team wrote programs that ran unattended in the background, copying files to tape during idle periods.

These background programs had no precedent and needed a name. The MIT team, many with physics backgrounds, borrowed Maxwell's Demon — a thought experiment from James Clerk Maxwell (1867) where an invisible being sorts fast and slow molecules between two chambers. Corbató later recalled:

We fancifully began to use the word daemon to describe background processes that worked tirelessly to perform system chores.

The spelling daemon (with an a) follows the ancient Greek form, where a daemon was a helpful spirit between gods and humans, not an evil devil. Early Chinese Unix translators rendered it as 守护进程 (guardian process) to capture this benevolent sense.

Adoption in Unix and the Naming Convention

The term traveled to Bell Labs when Ken Thompson and Dennis Ritchie, both veterans of the MIT-led Multics project, created Unix in 1969. Early teletypes and character terminals were narrow; the ps command showed only a few letters per process name. To distinguish background daemons from interactive commands at a glance, Unix established a convention: daemon executables would end with d. Thus the remote-login client is ssh and its server sshd; the cron scheduler becomes crond; the internet superserver inetd; and modern examples include dockerd and systemd.

The BSD Mascot and the fork() Pun

In 1984, John Lasseter (later co-founder of Pixar) drew the BSD mascot Beastie — a red, horned demon wearing sneakers and holding a trident. The trident is a visual pun: in English it is called a fork, and the first step in writing a Unix daemon is to call the system function fork() to create a child process. The parent then exits, leaving the child to call setsid() and detach from the controlling terminal, becoming a true background process.

Daemons as Orphan Processes

In the process hierarchy, a daemon is effectively an orphan process . Its creator exits immediately, so the daemon is adopted by the process with PID 1 — historically init, now usually systemd — and runs until shutdown.

The Backronym and a Procurement Scare

When Unix spread to enterprises and government in the 1980s, some non-technical buyers saw daemon throughout documentation and suspected programmers had inserted occult references. Unix System Administration Handbook author Evi Nemeth explicitly debunked this. To avoid such confusion, someone later invented the backronym Disk And Execution MONitor — a plausible-sounding but entirely retrofitted expansion.

Conclusion

The trailing d in sshd, dockerd, and systemd does not come from a monitoring manual; it traces back to a 1867 physics thought experiment, carried forward by MIT's CTSS team, baked into Unix culture, and preserved in every modern Linux daemon name.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

fork system callLinuxdaemonsystemdUnix historyFernando CorbatóMaxwell's Demonprocess naming convention
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.