Understanding Daemons

> The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills.

Systemd apologists always seems to think that anyone not completely in love with systemd, is just refusing to learn something new. Please stop with the stupidity, people have real reasons to hate that shit.

I had no problem with switching to WireGuard, after learning about it, because this is so much better in both use and design than OpenVPN that I have used for 20 years. I had no problem with learning about systemd either, but that is just badly designed software to me.

Why do you stumble up on holes, when all you need to know to make a daemon is described in APUE in detail and in hundreds of books and articles? Making a daemon, either via systemd or a classical way, is learning something new.

"We need a process without a process group, session, controlling terminal and mount point. How to do that? Well, fork two times, setsid, chdir, close all descriptors. Let's call that daemon for short."

If one does not understand what all of this really means, or why all of this is part of a question, who do they blame against learning something new?

I was a fan of upstart. It was simple, it knew how to perform the task it did it, it didn't try to be everything plus the kitchen sink, it worked well and it didn't get its tendrils in everything like systemd does (something that concerns me as it increases the attack surface).

It was a technically superior solution murdered by politics.

What's worse was all of the people who were going "why are you moaning? what's wrong? systemd is still an improvement on sysvinit!" as if being better than a bunch of bash scripts held together with bits of sticky tape and string was all the qualification needed to be PID 1.

System administration tooling was famously not addressed by IEEE 1003.1 or 1003.2 originally in the 1980s. It hasn't been addressed since, either.

In practice, service managers have been around since 1988.

* http://jdebp.uk./FGA/unix-service-access-facility.html

What do you mean by the one-way trapdoors?

Oh! The good daemons! "benevolent or benign nature spirits...". Not in the Judeo-Christian tradition, for sure :-)

Also got me curious about the C.S. ethymology of the word. According to the venerable Jargon File (which has entries for both "daemon" and "demon"), it is named in honor of one of Maxwell's thought experiments! [1]

1: http://www.catb.org/jargon/html/D/daemon.html

Sorry you don't share my sense of humor! I've seen countless conversations about psychology subjects here at HN so I thought someone would find this subject interesting.

I have to admit to pronouncing it consistently “daymonization” and sometimes but not always “demon”.

But the first sentence has both pronunciations...so...

It's also not spelled "paediatrician" in American English, hence the confusion.

To be fair, it's not obvious how to pronounce a way it's spelt. e.g. "record" and "record" are pronounced differently, but have the same spelling.

The poem "Dearest creature in creation" is a fun illustration of the differences between spelling and pronunciation.

That's still a good practice, if you close descriptors. Such criticism and trouble comes from environments that are unable to follow the routine because reasons, e.g. they openlog() and construct other objects before daemonizing. Given how much can happen before python's main() to be called, it is obvious that daemonizing python-anything is a bad idea to start with. It only works for few controlled steps at int main(), after that you're screwed. All these pitfalls are discussed in literature, the real problem is that barely anyone bothers to read it and think for a second on their options. One of them being to use a proper service manager instead, like systemd.

Some distributions, for example Slackware, don't have it at all.

A bit of both. My computer does not have the "service" command at all. While it's true that many systems still do, it's typically there as a legacy compatibility layer, to translate SysV style commands to systemd.

So while the command might work for many readers, I don't think it's a good idea to send beginners that way, and its inclusion (without any footnotes or other qualifications) suggests that the author's knowledge is out of date.

Yeah, I've done some python daemons in win, and registered with the service control manager, but I was wondering what the "magic" was there.

Jobs, more precisely, nested jobs, are one of the best things (IMHO) that were added to Windows 8 from a technical point of view (then again, there ain't many good things added in Windows 8). I had to write a work-manager sort of application that would need to start worker subprocesses (which may also start some other subprocesses, which may or may not be programs under my control) and one of the requirements was that if the main process crashed, all the worker processes should be terminated (imagine if a part of what a worker process is supposed to do is to listen on some well-known TCP ports and provide an HTTP API on it: you can't restart the main process without killing the workers off first).

On Linux, it turned out to be surprisingly tricky. Process groups and sessions are not nested, you can easily break out of them and in fact there were some programs we needed to use that insisted on doing daemonization. Thankfully the most important one had a "--foreground" flag but it still was buggy: this program sends SIGTERM to its process group as part of a shutdown — so it kills its parent, too. Amazing. In the end I believe we ended running each worker process as a separate Docker container.

Then there is a dance of waiting (or not waiting? SIGCHILD is truly horrible) on children PIDs to detect the crashes and unexpected hang in the shutdown (the worker process sends "I am done" notification to the parent, but then for some reason doesn't exit). The main process had to be made a sub-reaper to do all of that more or less reliably, and even then there were some strange sightings (signal handling is fun!).

On Windows, we just shoved each worker process into its own unbreakable-from job, and that was it. The main process dies for whatever reasons, its children just disappear. A worker process dies, its children just disappear, without affecting any other worker processes and their children. Detecting termination of the child processes too was a breeze: on Windows, when you spawn a child process you get not only its PID, but also a handle (think "file descriptor") to it. This handle refers exactly to this process, and you can (interruptibly) wait on it, and when the last open descriptor to a process is closed, the process is deleted from the process table. That's why BTW there is no PID 1 that is constantly reaping its children on Windows: each process implicitly has its own handle alway open, so if the parent exits before the child does, nothing bad happens: The child process had 2 open handles on it, now it has 1. When it itself exits, the last handle is dropped, and the slot in the process table is cleaned.

TL;DR: Process management is horrible, use Erlang.