Understanding Daemons

With systemd (and afaik other service managers) you don&#x27;t need&#x2F;should to do all that daemonization dance. The application can run in the foreground, keep any fds open, don&#x27;t worry about tty etc because the service manager will take care of them for you. As a cherry on top, anything you write on stdout gets automatically forwarded to journald or wherever.<p>further reading <a href="https:&#x2F;&#x2F;www.man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;daemon.7.html" rel="nofollow">https:&#x2F;&#x2F;www.man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;daemon.7.html</a>

&gt; Simply put, a daemon (pronounced dee-mon) is an intentionally orphaned background process. Additionally, daemons are detached from the terminal in which they’re spawned, operate without user interaction, and are descendants of the system’s init process.<p>A memorable way to think about this is that a daemon is a child process whose parent has literally disowned it, forked off, and died.

Of all the great content in APUE, I think W. Richard Stevens’ (RIP) coverage of daemonization is the only piece I’ve ever used.<p>Fortunately I recently replaced my lost 1st edition with a 2nd edition, and the coverage looks similar. From what I can see there are two details left out of this article:<p>* <i>Why</i> changing the working directory is important (so the daemon doesn’t accidentally prevent a file system from being unmounted in the future).<p>* WRS emphasized logging.<p>Some of the details are different (umask as the first function instead of the last), but the highlights are comparable.

I was hoping this would be an article for beginners to understand daemons, as in the Ancient Greek daimon (δαίμων: &quot;god&quot;, &quot;godlike&quot;, &quot;power&quot;, &quot;fate&quot;) :-)<p>Growing up on a (quasi fundamentalist) christian household, daemons were for a long while a very real threat, and my mom would not allow me to watch horror movies, &quot;receive things from strangers&quot;, an other procedures to protect us from &quot;inviting the daemons home&quot;.<p>My rational mind leaves no room for such creatures these days, but even so under the right circumstances, sometimes my lizard brain begins to think maybe the Bible (and my mom for that matter) was right :-). Hard to erase some emotive memories from childhood I guess.<p>A while ago I read this book [1] which is pretty cool, covers the mind mechanisms behind things like the placebo effect, &quot;daemonic possession&quot;, alien abductions, mass hysteria, out of body experiences, etc...<p>1: <a href="https:&#x2F;&#x2F;www.suggestibleyou.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.suggestibleyou.com&#x2F;</a>

Going by the spelling, isn&#x27;t it pronouced day-mon?

This function may do mostly the right thing in a process dedicated to it, but it is not safe to call as part of a more complex process - especially a multi-threaded one.<p>For example, malloc() may be holding on to a mutex in the parent process (on another thread), so subsequent malloc() calls in the child process will block waiting for the mutex to be released. Closing the file handles may help if this was a kernel mutex, but it may not help if this was a user-space mutex.<p>In general, fork() without exec() is only safe as the first thing done in a process.<p>Also, it looks like there is a minor race condition in the implementation: since the original process exit()s immediately after the fork(), control will return to its parent, which may close the session - this could happen before the child had a chance to call setsid() and detach from the parent session.

A good practice for a classical daemon and any program in general after closing all descriptors is to reopen first three (0,1,2) to &#x2F;dev&#x2F;null. After that, any forgotten or unexpected diagnostics (rare printf in third party library) would not corrupt your open files.

&gt; Conventionally, daemon process names end with the letter “d”. If you’re interested in seeing all daemons installed on your Linux machine, use this command:<p>&gt; service --status-all<p><pre><code> $ service --status-all bash: service: command not found</code></pre>

So how does this work in windows? Edit, as for some reason it&#x27;s getting downvoted: In windows, do you have to do the double fork etc? Do you have to close FDs etc?

Very timely to see this. I was trying to daemonize some celery workers&#x2F;celery tasks and I wasn&#x27;t sure how to go about it. Glad this came up

They have a double fork - forked tongue and forked tail, and often cannot be killed through normal means, re-spawning with the aid of an even greater evil known as SystemD.