What Is a Daemon in Computing and How Does It Work?

A daemon is a program that runs in the background without a user interface, typically starting at boot or on demand and continuing to run until it is stopped or the system shuts down. You interact with it indirectly—through a client, a socket, a config file, or a command—rather than by clicking around inside the daemon itself. Music Player Daemon (MPD) is a concrete example: it is a server-side application that plays music, and you control it from a separate client.

What makes a process a daemon

The defining trait is not what the program does but how it runs:

• No controlling terminal. A daemon detaches from the terminal that launched it, so closing that terminal does not kill it.
• Long-lived. It stays resident and waits for requests or events instead of doing one job and exiting.
• Started automatically or on demand. It can be launched at boot by the init system, or started manually and left running.
• Controlled indirectly. Configuration files, control commands, sockets, or client programs are how you talk to it.

A foreground app, by contrast, owns your terminal or window, shows you output directly, and usually ends when you close it.

How a daemon starts and keeps running

The typical lifecycle looks like this:

1. Launch. Either the system's init/service manager starts it at boot, or you start it yourself.
2. Detach. The process separates from the controlling terminal and often changes its working directory and file descriptors so it is not tied to a login session.
3. Listen or wait. It opens the resources it needs—network sockets, files, devices—and then idles until something requests work.
4. Serve repeatedly. It handles requests or performs its function continuously.
5. Stop. It ends when explicitly told to stop, when it crashes, or at shutdown.

Not every daemon follows every step identically, but the pattern of "start, detach, wait, serve" is the common shape.

MPD as a worked example

Music Player Daemon fits the model well. Per its own description, MPD is "a flexible, powerful, server-side application for playing music." The "daemon" in the name is literal: it runs in the background as a server, and the music playback happens inside that server process rather than in a window you watch.

The split of responsibilities is the useful part to understand:

So when you press play in a client, you are not playing audio in the client. You are asking the daemon to do it. That is the essence of a daemon: the work happens in a background service, and your interface is a thin layer on top.

MPD's ecosystem reflects this. The project's news feed, for instance, announces client releases such as "myMPD 26.0.0 has been released"—a separate front-end that talks to the daemon. The daemon and its clients evolve independently, which is only possible because the daemon is a standalone background service.

Daemons vs. foreground apps vs. system services

These terms overlap, so it helps to separate them:

• Daemon — a background process, traditionally detached from a terminal. The term is about the process's relationship to the user and the terminal.
• Foreground application — a program you run and interact with directly; it typically ends when you close it.
• System service — a broader category of managed background functionality. On modern systems, services are usually supervised by the init system, and many services are daemons. A service can also be something the supervisor manages that is not strictly a classic detached daemon.

In practice, "daemon" and "service" are often used loosely for the same thing. The precise distinction is that "daemon" describes the process style, while "service" describes the role of providing ongoing functionality to the system or other programs.

The trailing "d" naming convention

You will notice many daemons end in d:

• httpd — web server daemon
• sshd — secure shell daemon
• crond — scheduled-task daemon
• mpd — Music Player Daemon

The "d" is shorthand for "daemon." It is a convention, not a requirement—plenty of daemons do not use it—but it is a fast visual cue that a program is meant to run in the background.

Why this matters when you use MPD

Understanding the daemon model explains MPD's behavior:

• Closing your client does not stop the music. The daemon keeps playing because playback lives in the daemon, not the client.
• Multiple clients can connect. Because the daemon is a server, several front-ends can talk to the same instance.
• Configuration is separate from control. You set up the daemon once (music directories, outputs, connection details), then control it repeatedly from clients.
• The daemon must be running first. If it is not started, clients have nothing to connect to.

That last point is the most common practical snag: a client that cannot reach MPD is usually a client looking for a daemon that is not running or is listening somewhere the client is not configured to find.

Quick way to decide if something is a daemon

Ask three questions:

1. Does it run without a window or terminal you watch?
2. Does it keep running and wait for requests or events?
3. Do you control it through a client, command, socket, or config rather than direct interaction?

If the answers are yes, you are dealing with a daemon—and MPD is a clean example of one.