← Back to context

Comment by masklinn

4 years ago

Isn't the first use-case a pretty debatable / bad one? By daemonizing internally, you make service management and supervision of the program much more difficult, and if you include a non-daemonizing mode for debugging you now have two different runmodes with a pretty significant semantics difference, only one of which is easily inspectable.

Daemonizing is a thing of the past with modern restarter frameworks, like SMF, systemd, supervisord, etc. But daemonizing was always an option, not a requirement, and as an option, it's safe enough to provide it for those who don't use a restarter.

Your program probably knows how (if it wished) to manage its own resources far better than an external program ever could.

  • Said no sysadmin ever.

    • I love this sysadmin comment and the GP dev comment. The key is to get the sysadmin team putting requirements to the code, whether the restarting ends up in process or as a nice small unix separate tool that just does restarts well, is an outcome of a process.