nomenclature – What is a daemon?


I know that “demon” comes from the Latin daemon , but I believe this word has another meaning in the technological environment.

What is a daemon? What do you eat? What is it for?


Etymology of the word daemon:

In a Virginia Tech/Norfolk State University document entitled The Origin of the word Daemon is the explanation for the origin of the word "daemon":

I write a trivia column for a newspaper called The Austin Chronicle. Someone asked me the origin of the word daemon when referring to computing. The best I can say based on my research is that the word was first used by people on your Project MAC team using the IBM 7094 in 1963. The first daemon (an abbreviation of Disk And Executive MONitor) was a program that automatically backed up the file system to tape.

Richard Steinberg of The Austin Chronicle

Your explanation of the origin of the word daemon is correct, as my group started using the term around this time. However, the explanation of the acronym is new to me. Our use of the word daemon was inspired by Maxwell's daemon of physics and thermodynamics. (My training is physical). Maxwell's daemon was an imaginary agent that helped classify molecules of different speeds and worked tirelessly in the background. Fancifully, we started using the word daemon to describe background processes that worked tirelessly to perform system tasks. I found a very good explanation of all this online at: (Search on "Maxwell" to locate the relevant paragraph.)

Fernando J. Corbato MAC project engineer

[Warning: This paragraph is about science, so if this topic causes you undue alarm, close your eyes until you've finished reading it.] 19th century scientist James Maxwell once daydreamed (the polite term is "mind experiment ") about a physics problem. He imagined a closed container divided in half. In the middle of the partition was a small gate, just big enough to admit a gas molecule. This gate, in Maxwell's imagination, was operated by a small daemon. This daemon observed the speed (that is, temperature) of the molecules heading towards the gate and, depending on the speed, let them pass. If he let only the slow molecules pass from side A to side B and only fast molecules pass from side B to side A, then A would be hot while B cooled. Maxwell's dmon was just imaginary, of course, but because it seemed to escape the laws of thermodynamics, it caused quite a stir. In the end, however, the theory of quantum mechanics showed why it would not work. [OK, you can open your eyes now.]

As you probably know, "system processes" called daemons monitor other tasks and perform predetermined actions depending on their behavior. This is so reminiscent of Maxwell's daemon observing its molecules that we can only assume that whoever dubbed these "system processes" had Maxwell's daemon in mind. Our assumption was confirmed to us directly by Professors Corbato and Saltzer, who worked on a system development project at MIT in 1963 known as Project MAC. They and their team members first used the daemon in this sense at that time, building on Maxwell's daemon.

Paragraph from quoted above by Fernando J. Corbato.


From Wikipedia :

On multitasking operating systems, a daemon is a computer program that runs as a background process rather than under the direct control of an interactive user. Traditionally, a daemon's process name ends with the letter d, to make it clear that the process is, in fact, a daemon, and to differentiate between a daemon and a normal computer program. For example, syslogd is the daemon that implements the system logging feature and sshd is a daemon that serves incoming SSH connections.

From linux man-pages :

A daemon is a service process that runs in the background and oversees the system or provides functionality to other processes. Traditionally, daemons are implemented following a scheme that originated in SysV Unix . Modern daemons should follow a simpler but more powerful scheme (here called modern daemons) as implemented by systemd .


SysV Daemons(Old Style) : (Extracted from linux man-pages )

When a traditional SysV daemon is started, it must perform the following steps as part of startup. Note that these steps are unnecessary for restyled daemons (see below), and should only be implemented if SysV compatibility is essential.

  1. Closes all open file descriptors except standard input, output, and error (ie the first three file descriptors 0, 1, 2). This ensures that no file descriptors are accidentally passed to the daemon process. On Linux, this is best implemented by iterating through /proc/self/fd , with a fallback from file descriptor iteration 3 to the value returned by getrlimit() for RLIMIT_NOFILE .

  2. Resets all signal handlers to their defaults. This is best done by iterating through the available signals up to the NSIG boundary and resetting them to SIG_DFL .

  3. Resets the signal mask using sigprocmask() .

  4. Sanitizes the environment by removing or resetting environment variables that can negatively impact the runtime daemon.

  5. Call fork() to create a background process.

  6. In the child process, it calls setsid() to detach from any terminal and create an independent session.

  7. In the child process, it calls fork() again, to ensure that the daemon can never re-acquire a terminal again. (This is relevant if the program, and all of its dependencies, does not carefully specify O_NOCTTY on every open() call that could potentially open a TTY device node.)

  8. Calls exit() on the first child, so only the second child (the actual daemon process) remains. This ensures that the daemon process is redirected to init/PID1 , as all daemons should be.

  9. In the daemon process, connect `/dev/null' to standard input, output and error.

  10. In the daemon process, reset the umask to 0, so that the file modes passed ​​to open() , mkdir() and the like directly control the access mode of the created files and directories.

  11. In the daemon process, change the current directory to the root directory ( / ) in order to prevent the daemon from preventing mount points from being unintentionally unmounted.

  12. In the daemon process, write the daemon's PID (as returned by getpid() ) to a PID file, for example /run/ (for a hypothetical "foobar" daemon) to ensure that the daemon cannot be started anymore at once. This should be implemented in a race condition free way, so that the PID file is only updated when it is checked at the same time that the PID previously stored in the PID file no longer exists or belongs to a foreign process.

  13. In the daemon process, cancels the possible and applicable privileges.

  14. From the daemon process, notify the original started process that initialization is complete. This can be implemented via an anonymous pipe or similar communication channel that is created before the first fork() and therefore available in both the original and daemon processes.

  15. Call exit() in the original process. The process that invoked the daemon must be able to ensure that this exit() happens after the initialization is complete and all communication channels have been established and are accessible.

Modern daemons: (Extracted from linux man-pages )

Modern services for Linux must be implemented as a new style of daemons. This makes it easier to supervise and control them at runtime and simplifies their implementation.
To develop a new style daemon, none of the initialization steps of the recommended steps for SysV daemons need to be implemented. New boot systems like systemd make them all redundant. Also, since some of these steps interfere with process monitoring, file descriptor passing and other boot system functionality, it is recommended not to run them when running with a modern service.

Note that modern boot systems guarantee running daemon processes in a clean process context, which is to ensure that the environment is sanitized, that the signal and mask handles are reset, and no remaining file descriptor leftovers are passed.
Daemons will run in their own session, with standard input connected to /dev/null and standard output/error and standard output/error connected /dev/null and standard output/error connected to the logging service systemd-journald.service() , unless otherwise configured. The umask is reset.

It is recommended for modern daemons to implement the following:

  1. If SIGTERM is received, shut down the daemon and exit cleanly.

  2. If SIGHUP is received, reload the configuration files if this applies.

  3. Provide a correct exit code from the main daemon process as this is used by the init system to detect service errors and problems. It is recommended to follow the exit code scheme as defined in the LSB recommendations for SysV init scripts.

  4. If possible and applicable, expose the daemon's control interface through the IPC D-Bus system and take a bus name as the last boot step.

  5. For systemd integration, provide an a.service unit a.service that carries information about starting, stopping, and using the daemon. See systemd.service for details.

  6. As much as possible, rely on boot system functionality to limit the daemon's access to files, services and other resources, ie in the case of systemd , which rely on systemd resource limit control rather than implementing its own, have the privilege of dropping systemd code instead of deploying it to the daemon and the like. See systemd.exec() for available controls.

  7. If D-Bus is used, make your daemon bus-enabled by providing a D-Bus service enablement configuration file. This approach has several advantages: your daemon can be delayed from starting.
    On demand it can be started in parallel with other daemons which maximizes parallelization and boot speed.
    Quickly, your daemon can be restarted in case of failure without losing any bus requests as the bus queues requests for activatable services.

  8. If your daemon provides services to other local processes or remote clients via a socket, it should be made socket-activatable following the scheme given below. Like enabling D-Bus, this allows for on-demand start of services as well as better parallelization of service startup. Also, for stateless protocols (such as syslog , DNS ), a daemon that implements socket-based activation can be restarted without missing a single request.

  9. If applicable, a daemon must notify the boot system of boot completion or status updates via the sd_notify(3) interface.

  10. Instead of using the syslog() call to log directly to the system's syslog service, a modern daemon might choose to simply log the standard error via fprintf() , which is then forwarded to syslog by the boot system. If logging levels are required, they can be encoded by prefixing individual log lines with strings like "<4>" (for level 4 log "WARNING" in syslog priority scheme), following a similar style to Linux Kernel call printk() at the system level. For details, see sd-daemon() andsystemd.exec() .

  11. As modern daemons are called without a controlling TTY (but like their own session headers) care must be taken to always specify O_NOCTTY in open() calls that possibly reference a TTY device node, so that no controlling TTY is accidentally acquired.

The recommendations are similar to but not identical to the Apple MacOS x Daemon Requirements .

On other operating systems:

Microsoft DOS TSR : Excerpt from Wikipedia

A terminate-and-stay-resident program (usually TSR) is a computer program that runs under DOS that uses a system call to return control to DOS as if it has ended, but remains in the computer's memory so that it can be reactivated later. . This technique partially overcomes the DOS limitation of running only one program or task at a time. TSRs are only used in DOS, not Windows.

Although very useful, or even essential for overcoming the limitations of DOS , TSRs have a reputation as troublemakers. Many hijack the operating system in various documented or undocumented ways, often causing systems to lock up on or off when used with specific applications or other TSRs. Some viruses and other malware have been encoded as TSRs and are deliberately problematic. Furthermore, in DOS all programs, even those with large amounts of physical RAM, must be loaded in the first 640KB of RAM (the conventional memory) and TSRs are no exception and take chunks of that 640KB that therefore aren't available for other applications.

Microsoft Windows Services : (Excerpt from Wikpedia )

In Windows NT operating systems, a Windows Service (or Windows Service) is a computer program that operates in the background. It is similar in concept to a Unix daemon.
A Windows service must comply with the interface rules and protocols of Service Control Manager, the component responsible for managing Windows services. It is the Services and Controller application, services.exe, which launches all the services and manages their actions like starting, stopping, etc.

Windows services can be configured to start when the operating system starts and run in the background while Windows is running. Alternatively, they can be started manually or by an event.
Windows NT operating systems include several services that run under the context of three user accounts: System , Network Service and Local Service . These Windows components are often associated with the Host Process for Windows Services.
Because Windows services operate in the context of their own dedicated user accounts, they can operate when a user is not logged in.

Prior to Windows Vista, services installed as an "interactive service" could interact with the Windows desktop and show a graphical user interface. In Windows Vista, however, interactive services are deprecated and may not function correctly as a result of Windows Service protection.

Scroll to Top