Talk:Daemon (computing)

WRT "In a strictly technical sense, a Unix-like system process is a daemon when its parent process terminates and the daemon is assigned the init process (process number 1) as its parent process and has no controlling terminal. However, more generally, a daemon may be any background process, whether a child of the init process or not."

What sense is that? Who is the authority on this? Without context, this is gibberish.

I think the intent is that some people think a daemon has parent proc of 1, but that some don't. Is that about it? Stevebroshar (talk) 15:29, 24 May 2025 (UTC)

I'm not sure what the <insert four-letter word> they're trying to say. Perhaps they're trying to distinguish between background processes that the user runs with, for example, & in the shell and daemons, but 1) there's also the batch command, which lets the user run batch jobs that aren't attached to their terminal and 2) not all daemons on Unix-like systems have init as a parent process, and even those that do may have it as the parent because init spawned them (e.g., launched by launchd, which serves as the init process on Darwin-based OSes such as macOS and iOS), rather than because whatever process spawned them exited.

Absent a citation, that text should be removed. Guy Harris (talk) 08:57, 25 May 2025 (UTC)

I don't know whether any of the various authorities have really specified this, versus it being a convention for making a daemon that works to avoid various problems. A modern source that references the traditional method (while promoting systemd, which does a bunch of the work itself for daemons it spawns) is https://man.archlinux.org/man/daemon.7.en, which can also be found in various other manpage repositories. You can find similar descriptions in older sources, such as https://web.archive.org/web/20120104063024/http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16 for example, and references to the practice in others such as https://man.archlinux.org/man/daemon.3.en#BUGS and https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=3#CAVEATS.The difference between a daemon that's a child of pid 1 (whether that's init or systemd or something else) and one that doesn't is that the latter is more likely to be accidentally terminated if its user logs out or its parent process is killed or something like that. Much of what's involved in "properly" daemonizing, including getting reparented to pid 1, is about avoiding that sort of accidental termination. You might also look at it as a difference between daemon sensu stricto and sensu lato. Anomie⚔ 12:58, 25 May 2025 (UTC)

There are more than two senses. For this use of the word, there's sensu originali, as per the reference for the adoption of the term at Project MAC.^[1] That says little more about daemons other than that they're "background processes which worked tirelessly to perform system chores". One example of a daemon in the Compatible Time-Sharing System (CTSS), a Project MAC project developed by Corbató and others, was a backup daemon.^[2]

"DAEMON", in CTSS, was the backup daemon in question; it's referred to as a "a console-less foreground user". "Foreground" and "background" appear to refer to regular and batch processes, not to "interactive vs. daemon"; "console-less" covers "not attached to a terminal".^[3]

As for daemons in Unixes:

Version 6 Unix's init's functions are 1) running /etc/rc to perform startup operations, 2) running a <mono>getty</mono> on every terminal mentioned in /etc/ttys to allow logins, and 3) reaping child processes and restarting them if they're gettys. The only one of those that is done "in the background" is the reaping of child processes - /etc/rc is run as a part of starting the system before you have foreground and background, and the gettys are waiting for logins, so they're arguably foreground.^[4]

Version 7 Unix's init are similar.^[5] However, uucp had its own account, named uucp; that account's "shell" was the uucico program, which communicated with a uucico on the other end of a serial line (hardwired or dial-up). Running uucp or uux will, by default, run uucico to do the transfer; that uucico could be viewed as a daemon started from within a user session. It would connect (by dialing up a remote system if necessary) with a remote uucico by logging in as the appropriate account (normally uucp) and talking to the remote uucico started by getty; the latter uucico could be viewed as a daemon as well.^[6] That reference speaks of uucico being started by "a system daemon", without indicating what other daemons exist.

4.2BSD added daemons for various Internet services; they were launched from /etc/rc, and waited for connections. As they were run from a shell started by init, they ended up being children of init after that shell exited.

4.3BSD added <mono>inetd</mono>, a super-server which listened on a number of TCP and UDP ports and launched daemons for the services on those ports when a connection was made; those daemons would be children of inetd, not init.

Apple's launchd and the Linux systemd function as init processes (process 1) and as super-servers; the servers they launch run as their children.

None of those, or the daemons they launch, are children of anything other than themselves or process 0 (for process 1) or of whatever launcher launched them, and none of them are attached to a controlling terminal, so they don't need to do the

In a Unix-based system, the parent process of a daemon is often, but not always, the init process. A daemon is usually created either by a process forking a child process and then immediately exiting, thus causing init to adopt the child process, or by the init process directly launching the daemon. In addition, a daemon launched by forking and exiting typically must perform other operations, such as dissociating the process from any controlling terminal (tty). Such procedures are often implemented in various convenience routines such as daemon(3) in Unix.

dance. I'm not sure what that dance is for, other than daemons run from a process in a command-line session.

I'm not sure which of those are the "strict sense" or the "broad sense" of a daemon on a UN*X. I'd say the dance isn't particularly relevant here, as this page is about the general notion, not about daemons on UN*Xes in particular.

BTW, "In a strictly technical sense, a Unix-like system process is a daemon when its parent process terminates and the daemon is assigned the init process (process number 1) as its parent process and has no controlling terminal." seems a bit bogus:

• If "system" applies to "process", with "system" being an adjective, then, as noted, system process of that sort are started by init or some other super-server, so, under normal operation, they never get process 1 assigned to them when the parent process terminates, and are never attached to a terminal and have never in their lives been attached to a terminal. uucico may be an exception, but it's a rare one.
• If "Unix-like" applies to "system", with "system" being a noun, then a background job I fire up with & may become a child of process 1 if I log out or close a terminal-emulator window, and it may get detached from the terminal at that point, but I'm not sure I'd call it a "daemon". Guy Harris (talk) 22:12, 25 May 2025 (UTC)
  • I'm not sure what that dance is for, other than daemons run from a process in a command-line session. Yes, probably that. As for the rest of your very long comment, I'm not seeing the relevance. You also seemed to skip over the whole sysvinit era, with runlevels and such, which may be important for understanding the dance. Anomie⚔ 22:47, 25 May 2025 (UTC)

The states, as they're called in System III's init, or runlevels, as they're called in System V's init, are irrelevant there. What matters is whether the daemons are spawned from an rc script run by an /etc/inittab entry, in which case the daemons work the same as they do when run from an rc file in the V7 or BSD init, or are spawned directly from an /etc/inittab entry, in which case, hey're run from init and don't have to do any demonization. In the first case, a subset of the dance, namely forking and having the parent exit, is needed iff the daemon is run without being backgrounded with &; otherwise, the backgrounding is done for the daemon and it doesn't need to bother doing the fork-and-exit. In the latter case, even that is unnecessary. It may be that the sole reason for the full dance is to allow the daemon to be run from a user's command line. Guy Harris (talk) 05:52, 26 May 2025 (UTC)