3 ms·

"these days it's somewhat controversial and sometimes considered undesirable" I respectfully disagree. It it fundamentally related to your use-cases, executio

"these days it's somewhat controversial and sometimes considered undesirable" I respectfully disagree. It it fundamentally related to your use-cases, execution times, and design paradigms. If your team comes from a *nix background, than having dozens of processes interfacing over various pipes/network-sockets/fifo/mem-share is normal. In a cluster environment, having the ability to spin up processes on any host, yet remain functional over middle-ware can be very robust from a maintenance perspective. A periodic self-restart trigger feature is only a small part of these feature sets. Containerization on the other hand was necessitated out of poor OS design consistency, and rotten permission handling. It added overhead, complexity, and costs. However, it also solved a very real user requirement of keeping many things operational at the same time. Daemons are almost certainly still required if you have software that must remain running for >6 months outside a users session. Also, periodic processes do not necessarily have to remain resident in all use cases if that was a concern. Best of luck, =3

zokier 2y ago
practically every system is running service manager of some sort (supervisord, daemontools, runit, or infamously systemd etc), and with a service manager daemonization is something between completely useless and actively harmful. as cks explains in the post, daemonization is truly relevant only if you are starting your daemons directly somehow somewhere, and that went out of fashion somewhere in the turn of the century.
- kazinator 2y ago
  Programs that deamonize should have a way (e.g. command line option) to opt-out of it, or opt-in. Unconditional daemonizing interferes with debugging, for instance. That's bad. But don't forget that the service managers themselves have to daemonize. :) The programs which they launch don't have to daemonize only because their parent did that already.
- Joel_Mckay 2y ago
  Interesting, I think we treat system services differently than utilities. A given host assigned capabilities should not require manual intervention, but should allow manual interaction for testing and debugging. Insisting one method is superior, is often from people that have never hit the terminal spawn limit on a host. Best of luck, =3

zokier 2y ago

practically every system is running service manager of some sort (supervisord, daemontools, runit, or infamously systemd etc), and with a service manager daemonization is something between completely useless and actively harmful. as cks explains in the post, daemonization is truly relevant only if you are starting your daemons directly somehow somewhere, and that went out of fashion somewhere in the turn of the century.

kazinator 2y ago
Programs that deamonize should have a way (e.g. command line option) to opt-out of it, or opt-in. Unconditional daemonizing interferes with debugging, for instance. That's bad. But don't forget that the service managers themselves have to daemonize. :) The programs which they launch don't have to daemonize only because their parent did that already.
Joel_Mckay 2y ago
Interesting, I think we treat system services differently than utilities. A given host assigned capabilities should not require manual intervention, but should allow manual interaction for testing and debugging. Insisting one method is superior, is often from people that have never hit the terminal spawn limit on a host. Best of luck, =3