6 ms·

Well, the rule appears to be: - Don't thread before you fork. - Don't lock before you fork. - Don't open before you fork. - Don't do anything that is not me

Well, the rule appears to be: - Don't thread before you fork. - Don't lock before you fork. - Don't open before you fork. - Don't do anything that is not meant to be a shared resource before you fork. Locks and threads is the worst. Locks can end up in weird states.

JdeBP 9y ago
Unless you are trying to implement systemd's "forking" readiness protocol for dæmons, in which case you have to adopt all of these problematic program design items. * http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#NooneSpeaksForking http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems...
- rcxdude 9y ago
  the "forking" 'readiness protocol' exists for backwards compatibility and interop, because it represents the behavior of many daemons designed for sysvinit style daemon management, or at least the behaviour they should have in order to avoid races between services in that model. It was not designed by systemd nor is recommended by them.
  - JdeBP 9y ago
    No, it does not. Read the answer that I hyperlinked.
    - arghwhat 9y ago
      Yes it does. To quote the article you linked, "What they are doing is trying to let system administrators start dæmons the 1980s way..." It is a compatibility mode, and it is broken beyond repair because the technique itself is broken beyond repair.
      - JdeBP 9y ago
        Trying. Now read the explanation of why it does not succeed, because no it does not represent the behaviours of these dæmons.
        arghwhat 9y ago
        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.
- arghwhat 9y ago
  Why would you do that? If you're designing for systemd, go for "simple" (that is, don't fork), or if you need to signal when your service is truly ready rather than just monitor its lifetime, go for "notify" (or "dbus" if you're into that sort of thing). Using "forking" as readiness protocol doesn't make sense. Unlike "notify", it doesn't signal readiness. It's only there to try to understand old services that always daemonize, which was only done because the old init systems required it. Daemonizing is pointless under systemd or other init systems that handle this themselves.

JdeBP 9y ago

Unless you are trying to implement systemd's "forking" readiness protocol for dæmons, in which case you have to adopt all of these problematic program design items. * http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#NooneSpeaksForking http://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems...

rcxdude 9y ago
the "forking" 'readiness protocol' exists for backwards compatibility and interop, because it represents the behavior of many daemons designed for sysvinit style daemon management, or at least the behaviour they should have in order to avoid races between services in that model. It was not designed by systemd nor is recommended by them.
- JdeBP 9y ago
  No, it does not. Read the answer that I hyperlinked.
  - arghwhat 9y ago
    Yes it does. To quote the article you linked, "What they are doing is trying to let system administrators start dæmons the 1980s way..." It is a compatibility mode, and it is broken beyond repair because the technique itself is broken beyond repair.
    - JdeBP 9y ago
      Trying. Now read the explanation of why it does not succeed, because no it does not represent the behaviours of these dæmons.
      - arghwhat 9y ago
        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.
arghwhat 9y ago
Why would you do that? If you're designing for systemd, go for "simple" (that is, don't fork), or if you need to signal when your service is truly ready rather than just monitor its lifetime, go for "notify" (or "dbus" if you're into that sort of thing). Using "forking" as readiness protocol doesn't make sense. Unlike "notify", it doesn't signal readiness. It's only there to try to understand old services that always daemonize, which was only done because the old init systems required it. Daemonizing is pointless under systemd or other init systems that handle this themselves.