What is a daemon?

Question

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

What is a daemon? What do you eat? What’s the point?

Answer 1

Etymology of the word daemon:

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

I write a curiosity column for a newspaper called The Austin Chronicle. Someone asked me the origin of the word daemon in what if refers to computing. The best I can say based on my research is that the word was first used by people of your team in the MAC Project using the IBM 7094 in 1963. The first daemon (abbreviated Disk And Executive Monitor) was a program that automatically made tape backups of the file system.
^{Richard Steinberg of The Austin Chronicle}

Your explanation of the origin of the word daemon is correct, for mine group started using the term around that period. However, the explanation of the acronym is new to me. Our use of the word daemon was inspired by Maxwell’s physics and thermodynamics daemon. (My formation is physical). Maxwell’s daemon was an imaginary agent that helped classify molecules at different speeds and worked tirelessly in the background. Fantastically, we began to use the daemon word to describe processes in the background that worked tirelessly to accomplish system tasks. I found a very good explanation about all this online at:

http://www.takeourword.com/TOW129/page2.html (Search in "Maxwell" to locate the relevant paragraph.)
^{Fernando J. Corbato MAC Project Engineer}

Description:

Of Wikpédia:

In multitasking operating systems, a daemon is a computer program that performs as a background process rather than being under the direct control of an interactive user. Traditionally, the process name of a daemon 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 input SSH connections.

Of linux man-pages:

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

Initialization:

Sysv Daemons(old style): (Extracted from the linux man-pages)

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

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

2. Reset all signal handlers to their standards. This is best done by iterating through the available signals to the limit of NSIG and redefining them to SIG_DFL.

3. Reboots the signal mask using sigprocmask().

4. Sanitize the environment by removing or redefining environment variables that can negatively impact the runtime daemon.

5. Flame fork() to create a process in the background.

6. In the process son, call setsid() to separate from any terminal and create a separate session.

7. In the process son, call fork() again, to ensure that the daemon can never regain a terminal again. (This is relevant if the program, and all its dependencies, do not carefully specify O_NOCTTY on each call open() that could potentially open a TTY device node.)

8. Flame exit() in the first child, so that 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, connects the `/dev/null' to the standard input, output and error.

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

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

12. In the daemon process, write the daemon PID (as returned by getpid()) for a PID file, for example /run/foobar.pid(for a hypothetical daemon "Foobar") to ensure that the daemon cannot be started more than once. This should be implemented in way free of running conditions, 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 daemon process, override possible and applicable privileges.

14. From the daemon process, notifies the original started process that the boot 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 processes, the original and daemon.

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

Modern daemons: (Extracted from the linux man-pages)

Modern services for Linux should 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 boot 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 ensure the execution of daemon processes in a clean process context, which is to ensure that the environment is sanitized, signal and mask handlers are reset and no leftover file descriptor is passed.
Daemons will run in their own session, with default input connected to /dev/null and output/standard error and standard output/error Connected /dev/null and standard output / error connected to the registry service systemd-journald.service(), unless otherwise configured. The umask is redefined.

It is recommended for modern daemons to implement the following:

1. If SIGTERM is received, closes the daemon and exits 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 output code scheme as defined in the LSB recommendations for Sysv startup scripts.

4. If possible and applicable, expose the daemon control interface via the IPC D-Bus system and take a bus name as the last step of the startup.

5. For integration into systemd, provide a drive file a.service which loads information on how to start, stop and use the daemon. See systemd.service for details.

6. As far as possible, rely on the functionality of the boot system to limit the daemon’s access to files, services and other resources, i.e. systemd, that depend on resource limit control of the systemd instead of implementing its own, count on the privilege of discarding the code of systemd instead of implementing it on the daemon and the like. See systemd.exec() for the available controls.

7. If D-Bus is used, make your daemon bus enabled by providing a D-Bus service activation configuration file. This approach has several advantages: your daemon may have delayed startup.
   On-demand 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 active services.

8. If your daemon provides services to other local processes or remote clients through a soket, it should be done as socket-enabled by following the schematic below. As the activation of D-Bus, this allows for on-demand start of services as well as allows for better parallelization of service startup. In addition, for stateless protocols (such as syslog, DNS), a daemon that implements soket-based activation can be restarted without missing a single request.

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

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

11. How modern daemons are called without a TTY control(but as your own session headers) one should take care to always specify O_NOCTTY on calls open() possibly referencing a device node TTY, so that no TTY control is accidentally acquired.

Recommendations are similar but not identical to Apple Macos x Daemon requirements.

In other operating systems:

Microsoft DOS TSR: Excerpt from the Wikpédia

A terminate-and-Stay-Resident program (usually TSR) is a computer program run on DOS that uses a system call to return control to DOS as if it had finished, but remains in computer memory so it can be reactivated later. This technique partially overcame 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 to overcome 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 crash on or off when used with specific applications or other Tsrs. Some viruses and other malware have been coded as Tsrs and are deliberately problematic. In addition, in DOS all programs, even those with large amounts of physical RAM, must be loaded in the first 640 KB of RAM (the conventional memory) and Tsrs are no exception and take pieces of these 640 KB that are therefore not 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 the Service Control Manager, the component responsible for managing Windows services. It is the Services and Controller, services.exe application, which launches all the services and manages their actions, like start, finish, etc.

Windows services can be set to start when the operating system starts and runs in the background while Windows is running. Alternatively, they can be started manually or by an event.
Windows NT operating systems include multiple services run in the context of three user accounts: System, Network Service and Local Service. These Windows components are often associated with 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.

Before Windows Vista, the services installed as an "interactive service" could interact with the Windows desktop and display a graphical user interface. In Windows Vista, however, interactive services are obsolete and may not function properly as a result of Windows Service protection.

Answer 2

Daemon is a process that runs in the background of an operating system. Basically, it is waiting for requests that will be made to the system, through the user, and handles these requests so that they can be met. It meets not only requests from the user, but also from the most diverse processes that need to run full-time in the system background as well, such as file indexing, software updates, data compression, web server,ssh server, among many other services.