3 ms·
No, that's a bad practice, because since the late 1990s service management subsystems have been as the norm setting up standard output and standard error so tha
by JdeBP 6y ago
No, that's a bad practice, because since the late 1990s service management subsystems have been as the norm setting up standard output and standard error so that they are connected to loggers. daemontools did it, once it gained svscan; and so did the other toolsets in the daemontools family such as runit, perp, s6, and others. systemd also does it, but is very much a latecomer here.
Furthermore, this bad practice lands one in hot water with library functions, including ironically syslog client libraries, that open and retain file descriptors internally for their own purposes. Yet another case of this was just on Hacker News this week, in fact, at https://news.ycombinator.com/item?id=24329540 https://news.ycombinator.com/item?id=24329540 .
- wruza 6y agoThat'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.
- JdeBP 6y agoNo-one can follow the routine. "daemonization" is a fallacy.