I love that Siebenmann is taking the time to document the nitty-gritty details of the evolution of Unix. Systems like 4.2BSD are long gone from the market, but we still see their influence all over the place.
"these days it's somewhat controversial and sometimes considered undesirable"
By whom and for what reason? Every non-trivial OS has some form of "daemon" concept, regardless of what name it's given. What alternative is proposed? All I get from this statement is discussion about the deficiencies of how demonization is performed.
They just mean service managers like SystemD and OpenRC prefer to handle daemonizing themselves, and thus would prefer that your program stay in the foreground and let them put it in the background.
From OpenRC’s docs[0]:
Daemons must not fork. Any daemon that you would like to have monitored by supervise-daemon must not fork. Instead, it must stay in the foreground. If the daemon forks, the supervisor will be unable to monitor it.
If the daemon can be configured to not fork, this should be done in the daemon's configuration file, or by adding a command line option that instructs it not to fork to the command_args_foreground variable shown below.
[0]: https://github.com/OpenRC/openrc/blob/master/supervise-daemo...
deamontools was the first supervisor service I used that required that programs not background themselves, it even included a tool for preventing "legacy" daemons from doing so.
It made a lot of sense to me at the time and honestly felt easier. Going back to init.d or upstart just felt like a step backward and so much more complicated that it needed to be. Then SystemdD comes along an have the same expectation and things makes sense again and writing "startup scripts became as easy almost as it was with daemontools.
inetd, the "super server" from 4.3BSD, supported this in addition to handling the listening socket. For reasons I don't fully understand, inetd fell out of favor despite having been installed and running by default on pretty much every *BSD and Linux server for decades.
> By whom and for what reason?
By everyone and for the reason that service managers lose track of the process, so it increases program complexity for a net negative in usability.
> Every non-trivial OS has some form of "daemon" concept, regardless of what name it's given.
And none of that is relevant, TFA is about the unix self-daemonization pattern, that is what's undesirable.
If your service manager cannot track forked process, that would be quite an issue anyway
"Daemonization" is nothing but fork + exec (and exit from the parent)
From the service manager, there should be few distinctions between this and, say, pgsql forking to handle connections. In both cases, I expect all child processes to be tracked.
And please do not tell me the "health check" part : having the main process alive is a broken health check, just like having a server powered-on is a far from enough
daemonization is the process of running a process in the background and without being attached to a terminal. Many applications exit when they are detached from the terminal they starter even when they yield no output. Maybe that is why it's still there. Of course back in the day fork() was all about creating background processes that were running quietly in the background were screen didn't exist yet and terminals were actual machines, not just one more window. Today System D doesn't like daemonization. IT prefers a process that can be attached somewhere.
I prefer non-daemon things that I can use systemd to manage with Unit files Type=Simple. Very easy, sends things to journal for logging. All very nice and clean. Self-daemonization is anti-pattern for new software. Non-UNIX DOTW.
Is there an archive link for this by any chance? I got a 403 error trying to load it with this message: "You appear to be trying to break this web server. Goodbye."
Yep! You can find copies of the article both on Wayback Machine and on archive.ph https://archive.ph/
Daemons suck if you're not in the microservices camp.
Can you explain further? daemons are OS-level and predate microservices by like a half-century, so how are they relevant to microservices?
If you're administering a server, what else is there?
There are service managers like systemd and shepherd, which use daemonization under the hood. Then there's container orchestration like docker compose, kubernetes, etc. For my toy servers at home I just use screen and have it set up automatically at boot.
What do you use outside of the microservices camp?