What Is a Daemon? The Process Nobody Watches

Updated: October 2026

Every server you look after runs dozens of programs that nobody launched by hand and nobody watches. That's the design, right up until one of them fills the disk or turns out to belong to someone who shouldn't be there. Here's what a daemon is, how Linux, macOS and Windows each run them, and how to check what's running on a machine you're responsible for.

What Is a Daemon?

A daemon is a program that runs in the background, with no terminal and no user attached to it. The system starts it, usually at boot, and it waits for work: a network connection, a timer, a file landing in a folder. When the work arrives, it handles it and goes back to waiting.

Three traits give a daemon away. Its parent is the init system (PID 1), not your shell. It has no controlling terminal, so closing your SSH session doesn't kill it. And it's built to run until someone stops it, where a normal command runs once and exits.

Unix tradition marks them with a trailing "d". sshd answers SSH logins, crond runs scheduled jobs, httpd serves web pages and syslogd collects logs. Not every daemon follows the convention, but when you see a process name ending in "d", it's a good first guess.

This r/linuxquestions thread asks the question in its simplest form. The answers land where this post does: every daemon is a process, not every process is a daemon, and on Windows the same thing is called a service.

Where the Name Comes From

The word came out of MIT's Project MAC in 1963. Fernando Corbató's team borrowed it from Maxwell's demon, a thought experiment in physics about a tiny creature sorting molecules with no one telling it to. Corbató described the programs as background processes that "worked tirelessly to perform system chores."

You'll also see "Disk And Execution MONitor" offered as the meaning. That's a backronym, invented after the word was already in use. Daemon in the computing sense has nothing to do with demons either, which is worth knowing the day a user spots daemon in a process list and opens a panicked ticket.

Daemons vs Windows Services

Windows has the same idea under a different name. A Windows service is a background program started by the Service Control Manager (services.exe), with no window and no logged-in user required. Many of them share a host process, which is why Task Manager shows so many copies of the Service Host. Our svchost.exe guide covers how to tell which service lives inside each one.

The plumbing differs across the three systems you're most likely to manage. The concept doesn't.

How to List, Stop and Disable a Daemon

On Linux, systemctl does nearly everything. Start with what's running and what's set to start at boot:

bash
systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service --state=enabled
systemctl status sshd

Stopping and disabling are two different jobs. stop ends the daemon now, and it comes back at the next boot. disable removes it from boot, and it keeps running until you stop it or restart. mask goes one step further and blocks it from starting at all, even when another unit asks for it.

On Windows, PowerShell gives you the same view. Get-CimInstance adds the two fields you'll want later, the executable path and the account the service runs as:

powershell
Get-Service | Where-Object Status -eq 'Running'
Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, PathName

More one-liners like these sit in our PowerShell commands guide, sorted by the ticket you're on.

NetworkChuck walks through the Linux side hands-on, starting, stopping and hunting down daemons with systemctl:

Daemons and Agents on macOS

macOS splits background jobs in two. Launch daemons are system-wide, run as root and start at boot whether anyone logs in or not. Launch agents belong to a user and run only while that user is logged in.

Where the .plist file sits tells you which is which, and who put it there. /System/Library/LaunchDaemons is Apple's. /Library/LaunchDaemons holds third-party daemons, installed by an admin. Agents live in /Library/LaunchAgents for every user and in ~/Library/LaunchAgents for one. Apple's launchd documentation spells out the split.

Since macOS 13, they also show up in System Settings under Login Items (Login Items & Extensions in newer releases). For a full list from the command line, sudo sfltool dumpbtm prints every login and background item the system knows about.

Why an Unknown Daemon Is a Security Question

A daemon starts on its own, runs with privileges and survives a reboot. That's exactly what an attacker wants after the first foothold. MITRE ATT&CK files it under Create or Modify System Process (T1543), with separate entries for systemd services, Windows services, launch daemons and launch agents.

This r/macsysadmin post shows the pattern on a Mac. A user pasted a fake "update" command into Terminal. One reply identifies it as a ClickFix lure that runs an infostealer and sets up persistence through Google Keystone, the name of Google's updater.

When a daemon or service shows up that you can't place, five checks sort the boring from the bad:

1. Path. Linux daemons usually run from /usr/sbin, /usr/bin or /usr/lib, Windows services from System32 or Program Files. A binary in /tmp, a user's home folder or AppData is a red flag.
2. Package. On Linux, rpm -qf or dpkg -S on the binary tells you which package installed it. No package means someone put it there by hand.
3. Signature. On macOS and Windows, check who signed the executable. Unsigned, or signed by a name you've never heard of, needs an answer.
4. Account. A helper that runs as root or LocalSystem when it has no reason to deserves a second look.
5. Age. Compare when the unit file or plist was created, or when the service's registry key was last written, with your last change window.

Persistence is also the quiet step in a ransomware attack, sitting between the first click and the damage. Checking one machine takes five minutes. Checking a fleet is a query. OpenFrame's Mingo reads endpoint state through osquery, including every running process and its path, so the same check can run across every managed device at once.

Daemons, in Short

A daemon is a background process the system starts and keeps alive, and a Windows service is the same idea with different plumbing. Knowing how to list them, stop them and read where they came from covers most of the tickets they cause. The rest is noticing the one that shouldn't be there.

Next, see how a single Windows host process can carry a dozen services in our svchost.exe guide, or how persistence fits into the bigger picture of a ransomware attack.