Talk:Daemon (computing)

Acronym legend?

The acronym expansion appears to be an urban legend. This query:

The first daemon (an abbreviation for Disk And Executive MONitor) was a program that automatically made tape backups of the file system. Does this sound about right? Any corrections or additions? Thank you for your time!

to Fernando J. Corbato, head of the CTSS project where the word entered the computer lexicon, prompted the following reply:

Your explanation of the origin of the word daemon is correct in that my group began using the term around that time frame. However the acronym explanation is a new one on me.

The page (it's in the article) which has this also notes that:

Professor Jerome H. Saltzer, who also worked on Project MAC, confirms the Maxwell's demon explanation.

So I'd say this one is pretty definitively "busted"! Noel (talk) 17:19, 18 Nov 2004 (UTC)

How is it busted? It would only be busted if Corbato had provided the actual etymology; instead it only remains unproven. --148.84.19.92

I found the article, and Corbato also says it's from Maxwell. See [1]. Beinsane 21:43, 15 Apr 2005 (UTC)

Popular type of daemons

• Web server
• FTP server
• IRC server
• Email server (POP3 and IMAP4) — Preceding unsigned comment added by Frap (talk • contribs) 05:09, 3 December 2005‎

poor processes

A daemon kills the parent and forces the orphan to become adopted. Sounds like an appropriate name. — Preceding unsigned comment added by 24.167.246.211 (talk • contribs) 23:24, 28 July 2006‎

interrupt

this is a discussion page, this is my experience, if you dont agree you can ASK what i want.a deamon is infact an interrupt routine. most CPU's have several states off activity and have the abbility to have a list off programs and routines that will be checked every interrupt state. this is done with the IRQ number, the Interrupt ReQuest number and that number can be found in a list which will refeer to the correct program and then give CPU time to that specific routine. An example is the soundcard that has such dedicated IRQ number which helps with a continous sound created from the sound-deamon working from the background and maintaining a steady stream off bitrated sound bytes. Not every interrupt is a deamon. deamons are dedicated routine with a special task, like the constant bitstream of a wave file 80.57.172.40 (talk) 14:25, 23 April 2025 (UTC)

a deamon is infact an interrupt routine No, it is not. A daemon is a process that's not attached to a user interface, but it's not code that is called from an interrupt routine. Code that is called from an interrupt is usually called an "interrupt service routine" or an "Interrupt handler". Don't confuse the two. Guy Harris (talk) 05:39, 22 May 2025 (UTC)

disk and execution monitor

I've never heard of this as an expansion for daemon. Sure, someone said that once or twice, but it's not common. IMO, not notable. Just bc something can be cited does not make it noteworthy. Just bc people find backronyms funny (yes I do too) does not make it worthy for inclusion. Plus: 'disk'? That is such an antiquated term today. Should be removed. Stevebroshar (talk) 15:04, 24 May 2025 (UTC)

The relevant text is

After the term was adopted for computer use, it was rationalized as a backronym for disk and execution monitor.

I guess "it was rationalized" means "somebody made up a name for it, for whatever rational or irrational reasons convinced them to do it". I certainly don't consider it worthy of inclusion in anything other than maybe an "In popular culture" section, and those sections are often themselves considered not worthy of inclusion, so I'd say "get rid of it". Guy Harris (talk) 09:13, 25 May 2025 (UTC)

I'm not going to fight over it, but I suspect if we remove all mention of it then we'll eventually get someone trying to re-add it when they've found the backronym presented as fact in some source. As far as "In popular culture", seems unlikely that computing daemons are in popular culture at all, outside of technobabble mentions in Hollywood hacking. Anomie⚔ 12:21, 25 May 2025 (UTC)

If you're going to keep it, at least include the "incorrectly" from the Jargon File reference, to emphasize that it's not short for "disk and execution monitor". A direct reference to somebody calling it that, rather than to somebody saying that somebody called it that, would be nice as well. Guy Harris (talk) 22:20, 25 May 2025 (UTC)

Done and done. Guy Harris (talk) 22:31, 25 May 2025 (UTC)

Confusing in Mac OS section

WRT "Later versions of classic Mac OS augmented these with faceless background applications: regular applications that ran in the background. To the user, these were still described as regular system extensions. The more modern macOS, which is Unix-based, uses daemons but uses the term "services" to designate software that performs functions selected from the Services menu, rather than using that term for daemons, as Windows does."

What does "To the user, these were still described as regular system extensions" mean. Who is describing? via docs? the UI?

"The more modern macOS ... uses daemons but uses the term "services" to designate software that performs functions selected from the Services menu, rather than using that term for daemons, as Windows does" Again, who's using the term? In what context? What does "that term" refer to? And what term does Windows use? It does not use 'daemon'. Stevebroshar (talk) 15:26, 24 May 2025 (UTC)

Windows uses the term "services" for at least some, if not all, daemons in the sense of this article. macOS uses the term "services" for the stuff in the Services menu, although there is not, as far as I know, a one-to-one correspondence between Services menu items and programs. For example, "New TextEdit Window Containing Selection" probably involves the program that owns the window that's currently active and has a selection, the TextEdit program, and possibly /usr/libexec/pboard, which "provides pasteboard services" according to its man page, although as there's no copying-or-pasting involved, perhaps not. Guy Harris (talk) 09:05, 25 May 2025 (UTC)

strictly technical sense?

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. 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.

"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".

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.

Version 7 Unix's init are similar. 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. 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)

References