7 ms·

the original poster showed two ways to achieve a better result with less coupling. Given that systemd is already pushing a myriad of other mechanisms not imple

the original poster showed two ways to achieve a better result with less coupling. Given that systemd is already pushing a myriad of other mechanisms not implemented by any other init daemon, one has to wonder why you are even trying to dismiss the argument rather than engaging with it. Is it that you think strong coupling is good in systems?

mjg59 12y ago
No. Right now if anyone implemented option 1 in an init daemon, applications using it would be coupled to that init daemon. So it doesn't reduce coupling. It's also worse than sd_notify() from a technical perspective - there's no mechanism for passing metadata such as the PID to track, or information about the failure, or watchdog support and so on. Option 2 is just shit. I'd prefer a cross-init mechanism for this. But there isn't one. What should systemd do? Just not implement anything until SMF and launchd developers agree to add support?
- nwmcsween 12y ago
  Figure out the problem or create a standardised way of doing it rather than making whatever systemd chooses the standard, you know discuss things.
- felixgallo 12y ago
  I think we can all agree that any mechanism is going to involve coupling; the question is, how much, and what limits does that impose? The proposed 'use unix pipes' architecture proposed by the original author ('option 1') doesn't bind a daemon to a particular operating system or init system, because it uses a kernel feature common to all unix variants. And of course it itself is a mechanism for passing metadata, so your argument doesn't make sense. Using a socket would also be fine, and if systemd chose to expose and document that socket API directly, rather than hiding it behind a C shim, that would be tolerable. But since systemd's modus operandi so far has been to attempt to become tightly coupled to every userland component, I'm not holding my breath.
  - mjg59 12y ago
    The underlying NOTIFY_SOCKET implementation is defined as a supported interface (http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...), and is documented (http://www.freedesktop.org/software/systemd/man/sd_notify.html http://www.freedesktop.org/software/systemd/man/sd_notify.ht..., see the Notes section).
    - felixgallo 12y ago
      That is not documentation, that is incomplete[1] notes in a man page of a library call. That said, that's getting pretty close to a correctly uncoupled implementation. [1] https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3 https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3
      - mjg59 12y ago
        The notes define that a socket name starting with @ is a Linux abstract namespace socket, so I don't see where "incomplete" comes from. You can quibble over whether the documentation meets your preferred style (and I'll admit it certainly is odd to reference the underlying implementation in the notes for the wrapper rather than the other way around), but it's a page of text, shipped with the code, that tells you everything you need to reimplement it.
        felixgallo 12y ago
        The link I included in my comment shows that the behavior is not actually what is stated in the notes. Do you have any documentation that describes the complete behavior?
        mjg59 12y ago
        That's how Linux abstract sockets work. They're documented in unix(7).
- mzs 12y ago
  Writing option 1 into a daemon is basically adding these SIX lines of code and a command-line option: #include <signal.h> ... int use_sigstop = 0; ... case 'S' : use_sigstop = 1; break; ... if (use_sigstop) (void)raise(SIGSTOP); ...
  - mjg59 12y ago
    Option 1 explicitly discusses using pipes, which aren't hugely easier than sockets. The downsides of overloading sigstop have been fairly widely discussed.
    - mzs 12y ago
      I was responding to, "Rather than requiring library code to notify systemd that the daemon is ready, use some existing trivial method." It's even simpler and as a bonus the SIGSTOP approach is compatible with upstart. But for a pipe it does get more complicated. Do you have sscanf? How about strtol? Should you use atoi? Might want to just roll a for loop of your own for three digit integers say. Or what if the other end of the pipe was closed? I have to ignore SIGPIPE. Should I use sigaction? Well signal should always be there. But is my daemon multithreaded? Shoot, looks like I have to fork and immediately exec a helper that does the write. See where this is going? And the code someone linked to here for sd_notify style socket communication instead of linking with systemd (you are using pkgtools right?) used MSG_NOSIGNAL precisely for these signal issues. Guess what, it was different in Linux before 2.2 or something, can't remember the details. Also it's different in some FreeBSD versions as well. I'm pretty sure it was different on Darwin. I can't remember about Solaris. HPUX? AIX? Your guess is as good as mine. It's a portability PITA. Anyway, I really really dig the simplicity of raise(SIGSTOP). Also yes there are some detriments to overloading the use of SIGSTOP like this, maybe a small performance one, and maybe there is some concern another root process could use kill to send it SIGSTOP. But I think the simplicity and reliability outweighs all that stuff I mentioned above if you go for a robust portable alternative using a pipe or socket. Plus I can make arguments in a similar vein about the environment variable that systemd uses internally which is not pretended with something like "SYSTEMD_" or "_" even, but I wouldn't cause it's just as silly as complaining about the detriments of using a signal in my mind.

mjg59 12y ago

No. Right now if anyone implemented option 1 in an init daemon, applications using it would be coupled to that init daemon. So it doesn't reduce coupling. It's also worse than sd_notify() from a technical perspective - there's no mechanism for passing metadata such as the PID to track, or information about the failure, or watchdog support and so on. Option 2 is just shit. I'd prefer a cross-init mechanism for this. But there isn't one. What should systemd do? Just not implement anything until SMF and launchd developers agree to add support?

nwmcsween 12y ago
Figure out the problem or create a standardised way of doing it rather than making whatever systemd chooses the standard, you know discuss things.
felixgallo 12y ago
I think we can all agree that any mechanism is going to involve coupling; the question is, how much, and what limits does that impose? The proposed 'use unix pipes' architecture proposed by the original author ('option 1') doesn't bind a daemon to a particular operating system or init system, because it uses a kernel feature common to all unix variants. And of course it itself is a mechanism for passing metadata, so your argument doesn't make sense. Using a socket would also be fine, and if systemd chose to expose and document that socket API directly, rather than hiding it behind a C shim, that would be tolerable. But since systemd's modus operandi so far has been to attempt to become tightly coupled to every userland component, I'm not holding my breath.
- mjg59 12y ago
  The underlying NOTIFY_SOCKET implementation is defined as a supported interface (http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...), and is documented (http://www.freedesktop.org/software/systemd/man/sd_notify.html http://www.freedesktop.org/software/systemd/man/sd_notify.ht..., see the Notes section).
  - felixgallo 12y ago
    That is not documentation, that is incomplete[1] notes in a man page of a library call. That said, that's getting pretty close to a correctly uncoupled implementation. [1] https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3 https://bugzilla.redhat.com/show_bug.cgi?id=820448#c3
    - mjg59 12y ago
      The notes define that a socket name starting with @ is a Linux abstract namespace socket, so I don't see where "incomplete" comes from. You can quibble over whether the documentation meets your preferred style (and I'll admit it certainly is odd to reference the underlying implementation in the notes for the wrapper rather than the other way around), but it's a page of text, shipped with the code, that tells you everything you need to reimplement it.
      - felixgallo 12y ago
        The link I included in my comment shows that the behavior is not actually what is stated in the notes. Do you have any documentation that describes the complete behavior?
        mjg59 12y ago
        That's how Linux abstract sockets work. They're documented in unix(7).
mzs 12y ago
Writing option 1 into a daemon is basically adding these SIX lines of code and a command-line option: #include <signal.h> ... int use_sigstop = 0; ... case 'S' : use_sigstop = 1; break; ... if (use_sigstop) (void)raise(SIGSTOP); ...
- mjg59 12y ago
  Option 1 explicitly discusses using pipes, which aren't hugely easier than sockets. The downsides of overloading sigstop have been fairly widely discussed.
  - mzs 12y ago
    I was responding to, "Rather than requiring library code to notify systemd that the daemon is ready, use some existing trivial method." It's even simpler and as a bonus the SIGSTOP approach is compatible with upstart. But for a pipe it does get more complicated. Do you have sscanf? How about strtol? Should you use atoi? Might want to just roll a for loop of your own for three digit integers say. Or what if the other end of the pipe was closed? I have to ignore SIGPIPE. Should I use sigaction? Well signal should always be there. But is my daemon multithreaded? Shoot, looks like I have to fork and immediately exec a helper that does the write. See where this is going? And the code someone linked to here for sd_notify style socket communication instead of linking with systemd (you are using pkgtools right?) used MSG_NOSIGNAL precisely for these signal issues. Guess what, it was different in Linux before 2.2 or something, can't remember the details. Also it's different in some FreeBSD versions as well. I'm pretty sure it was different on Darwin. I can't remember about Solaris. HPUX? AIX? Your guess is as good as mine. It's a portability PITA. Anyway, I really really dig the simplicity of raise(SIGSTOP). Also yes there are some detriments to overloading the use of SIGSTOP like this, maybe a small performance one, and maybe there is some concern another root process could use kill to send it SIGSTOP. But I think the simplicity and reliability outweighs all that stuff I mentioned above if you go for a robust portable alternative using a pipe or socket. Plus I can make arguments in a similar vein about the environment variable that systemd uses internally which is not pretended with something like "SYSTEMD_" or "_" even, but I wouldn't cause it's just as silly as complaining about the detriments of using a signal in my mind.