4 ms·

The "forking" readiness protocol precisely mimics daemon interaction from an old init script, and grants you all the certainty of readiness and information of s

The "forking" readiness protocol precisely mimics daemon interaction from an old init script, and grants you all the certainty of readiness and information of state that daemonization is capable of giving you: None. If you try to implement the forking readiness protocol (you mentioned that doing so would be problematic), you are doing something wrong. It only exists for compatibility with existing legacy services, which implement behavior that has been a bad idea and problematic since the 80's. I'm not personally a systemd fan, but no "forking" readiness problems can be attributed to systemd.

JdeBP 9y ago
No, it does not. I've pointed you at an explanation of how it does not twice now already, as well as laid it out explicitly right at the start of this thread by explaining what behaviours that programs avoid one has to actually instead adopt wholesale. I've also pointed out pretty clearly that next to nothing speaks this protocol, which would clearly not be the case if it were the behaviour of things that do. Please read properly.
- arghwhat 9y ago
  If you think "forking" is a broken readiness protocol, than you have misunderstood what the forking type is. If you instead of stopping at the title read the actual post you linked, you'd notice that it explains that the issue lies not in the forking protocol, but in that legacy applications cannot signal readiness. See the third and fourth paragraph in the "No-one speaks the forking protocol" chapter. It also explains how daemonizing is a bad idea altogether, but that's separate. The essence here is that init systems predating upstart/systemd/... did not have a readiness protocol. Instead, they generally assumed that a daemonized service was immediately available after the parent exited, as that was when the script continued. Forking is meant to pug The "forking" protocol is only meant to plug such an application into systemd, nothing more. It grants you zero readiness information (just like when it was started by a sysvinit script), as such information does not exist. It would be stupid to try to implement this protocol. It is nothing but a compatibility layer. If you have an actual counter-argument (so far you have only posted a link, and then restated that you posted that link several times), please present it. I don't mind being proven wrong.

JdeBP 9y ago

No, it does not. I've pointed you at an explanation of how it does not twice now already, as well as laid it out explicitly right at the start of this thread by explaining what behaviours that programs avoid one has to actually instead adopt wholesale. I've also pointed out pretty clearly that next to nothing speaks this protocol, which would clearly not be the case if it were the behaviour of things that do. Please read properly.

arghwhat 9y ago
If you think "forking" is a broken readiness protocol, than you have misunderstood what the forking type is. If you instead of stopping at the title read the actual post you linked, you'd notice that it explains that the issue lies not in the forking protocol, but in that legacy applications cannot signal readiness. See the third and fourth paragraph in the "No-one speaks the forking protocol" chapter. It also explains how daemonizing is a bad idea altogether, but that's separate. The essence here is that init systems predating upstart/systemd/... did not have a readiness protocol. Instead, they generally assumed that a daemonized service was immediately available after the parent exited, as that was when the script continued. Forking is meant to pug The "forking" protocol is only meant to plug such an application into systemd, nothing more. It grants you zero readiness information (just like when it was started by a sysvinit script), as such information does not exist. It would be stupid to try to implement this protocol. It is nothing but a compatibility layer. If you have an actual counter-argument (so far you have only posted a link, and then restated that you posted that link several times), please present it. I don't mind being proven wrong.