Editing Daemon (computing) (section)

===Unix-like systems===
In a [[Unix-like]] system, the [[parent process]] of a daemon is often, but not always, the [[init]] process. A daemon is usually created either by the init process directly launching the daemon, by the daemon being run by an initialization script run by init, by the daemon being launched by a [[super-server]] launched by init.

The init process in [[Research Unix]] and [[BSD]] starts daemons from an initialization script. A daemon started as a command in an initialization script must either [[Fork (operating system)|fork]] a child process and then immediately exit, or must be run as a background process using {{mono|&}}, so that the shell running the initialization script can continue after starting the daemon. In the former case, the daemon process run from the shell exits, thus causing init to adopt the child process that runs as the daemon; in the latter case, when the shell running the initialization script exits, the child daemon process is adopted by init.<ref>{{cite web |url=https://utcc.utoronto.ca/~cks/space/blog/unix/DaemonizationIsQuiteOld |title=(Unix) daemonization turns out to be quite old |date=October 3, 2024}}</ref>

The versions of init in [[UNIX System III|System III]] and in [[UNIX System V|System V]] can run arbitrary commands and can be configured to run them once or to restart them when they terminate.<ref>{{cite book |url=https://bitsavers.org/pdf/att/unix/System_III/UNIX_Users_Manual_Release_3_Jun80.pdf#page=682 |title=UNIX User's Manual, Release 3.0 |date=June 1980 |at=INIT(8)}}</ref><ref>{{cite book |url=https://bitsavers.org/pdf/att/unix/System_III/UNIX_Users_Manual_Release_3_Jun80.pdf#page=619 |title=UNIX User's Manual, Release 3.0 |date=June 1980 |at=INITTAB(5)}}</ref><ref>{{cite book |url=https://bitsavers.org/pdf/att/unix/System_V_Release_1/301-926_UNIX_System_V_Release_1_Administators_Manual_Jun82.pdf#page=119 |title=UNIX System Administrator's Manua Release 5.0 |date=June 1982 |at=INIT(1M)}}</ref><ref>{{cite book |url=https://bitsavers.org/pdf/att/unix/System_V_Release_1/301-905_UNIX_System_V_Release_1_Users_Manual_Jan83.pdf#page=679 |title=UNIX User's Manual System V |date=January 1983 |at=INITTAB(4)}}</ref> The former mechanism can be used to run initialization scripts; daemons started from those scripts behave the same as in Research Unix and BSD. The latter mechanism can be used to run daemons directly from init.

A daemon can also be launched from a user's command line.  However, daemons launched in that fashion typically must perform other operations, such as dissociating the process from any controlling [[tty (Unix)|terminal]] (tty). Such procedures are often implemented in various convenience routines such as ''daemon(3)''. A daemon launched by an initialization script need not do these steps, but doing so allows the daemon to be restarted by a user if it exits;<ref>{{cite web |url=https://utcc.utoronto.ca/~cks/space/blog/unix/DaemonizationAndRestarts |title=Daemonization in Unix programs is probably about restarting programs |date=October 5, 2024}}</ref> init itself would not restart them.<ref>{{cite web |url=https://utcc.utoronto.ca/~cks/space/blog/unix/InitWasNotAServiceManager |title=Traditionally, init on Unix was not a service manager as such |date=October 4, 2024}}</ref> Operations such a daemon must do include:

* Optionally removing unnecessary variables from environment.
* Executing as a [[background (computer software)|background task]] by [[fork (system call)|forking]] and [[exit (system call)|exiting]] (in the parent "half" of the fork). This allows daemon's parent (shell or startup process) to receive exit notification and continue its normal execution.
* Detaching from the invoking session, usually accomplished by a single operation, <code>setsid()</code>:
** Dissociating from the controlling [[tty (Unix)|tty]].
** Creating a new session and becoming the session leader of that session.
** Becoming a [[process group]] leader.
* If the daemon wants to ensure that it will not acquire a new controlling tty even by accident (which happens when a session leader without a controlling tty opens a free tty), it may fork and exit again. This means that it is no longer a session leader in the new session, and cannot acquire a controlling tty.
* Setting the [[root directory]] ({{mono|/}}) as the current [[working directory]] so that the process does not keep any directory in use that may be on a [[Mount (computing)|mounted]] file system (allowing it to be unmounted).
* Changing the [[umask]] to 0 to allow <code>open()</code>, <code>creat()</code>, and other operating system calls to provide their own permission masks and not to depend on the umask of the caller.
* Redirecting [[file descriptor]]s 0, 1 and 2 for the [[standard streams]] ([[stdin]], [[stdout]] and [[stderr]]) to {{mono|/dev/null}} or a [[Computer data logging|logfile]], and closing all the other file descriptors inherited from the parent process.

If the process is started by a [[super-server]] daemon, such as {{mono|[[inetd]]}}, {{mono|[[launchd]]}}, or {{mono|[[systemd]]}}, the super-server daemon will perform those functions for the process,<ref name=inetd>{{man|8|inetd|FreeBSD}}</ref><ref>{{man|5|launchd.plist|Darwin}}</ref><ref name=systemd_service>{{cite web|title=systemd.service|url=http://www.freedesktop.org/software/systemd/man/systemd.service.html|publisher=freedesktop.org|access-date=August 25, 2012}}</ref> except for old-style daemons not converted to run under {{mono|systemd}} and specified as {{mono|Type{{=}}forking}}<ref name=systemd_service/> and "multi-threaded" datagram servers under {{mono|inetd}}.<ref name=inetd/>