Comment by Joker_vD | Hacker News Reader

Comment by Joker_vD | Hacker News Reader

> Rather than having processes detach themselves from the terminal, these managers run daemons as if they were normal (albeit long-running) programs. This slightly simplifies the daemons themselves and provides a more homogeneous experience for the user.

It tremendously simplifies the daemons themselves and indeed does provide a more homogeneous experience for the user. Remember: do one thing only, and do it well. The "daemonizing" part is is a second thing and it belongs in a separate utility. If the user wants to run your daemon "interactively" (e.g. being able to press Ctrl-C to stop it), they should be able to do so by simply running your daemon from the shell. If the user wants to run your daemon "in the background", whatever it means to the user, they can arrange so by themselves. Why is it such a difficult idea for the "daemon" writers to accept is beyond me: there is negative value in a program forcefully detaching itself from every single way to supervise it (double- and triple-forking defeats supervising via wait(), closing FDs defeats watching for the closing of an injected pipe, etc).

Not to mention that in order to properly start and stop such double-forked daemons, you need everyone to agree on how pidfiles work, where to store them, how to garbage collect them, where to write logs, their permissions, how to rotate them, etc etc etc.

With the systemd/“just stay in the foreground” approach you just stay in the foreground and the process monitor can just wait() on you. And for logging you can just write to stdout and let the process monitor unify all the logging. Do one thing and do it well indeed.

> Why is it such a difficult idea for the "daemon" writers to accept is beyond me

Because the old documentation was good, and the new documentation is awful.

The old documentation often wasn't good.

But if you're trying to replace an existing system, it's a mistake to think "the old system had poor documentation so it's OK for the new system's documentation to be poor too", because people have already learned to cope with the old system.

I've seen people make that mistake distressingly often in recent years.

> Why is it such a difficult idea for the "daemon" writers to accept is beyond me

There's plenty of old documentation out there saying things like "a proper daemon completely detaches from its controlling terminal, opens log files, etc."

There is also plenty of old documentation that strongly advises against doing that, see [0] for references (e.g. the aside with an excerpt from the 1995-era AIX docs).

[0] https://jdebp.uk/FGA/unix-daemon-design-mistakes-to-avoid.ht...

> Why is it such a difficult idea for the "daemon" writers to accept is beyond me

Because the basic OS interface is a 50-year-old design with "terminals" being the central I/O entity.

Differentiating between "interactive" and "daemon" mode becomes tricky for a daemon writer. In interactive mode, SIGHUP must terminate your process. In daemon mode, you may interpret it any way you like. Same for SIGINT, SIGQUIT, SIGPIPE, etc.

Tricky? Checking if you're bound to TTY is trivial, checking whether you have a parent is trivial, checking whether interactive shell is somewhere in the tree is trivial, having some if's in signal handlers is trivial, etc.

Besides "daemon writers" could just default to foreground, because if it's ran as a daemon it is ran from a script hence nobody cares for extra option typing such as -d --daemon, it's written once in a file, as opposed to doing "program --foreground" every time you want it to run in front of you

Reply on news.ycombinator.com