3 ms·

"They're all wrong", followed by listing three mechanisms provided by systemd that get this right (socket activation, the dbus method, the notify method). The u

by mjg59 12y ago

"They're all wrong", followed by listing three mechanisms provided by systemd that get this right (socket activation, the dbus method, the notify method). The underlying problem is that there's no solution that's portable across init systems. That's not systemd's problem - ever other init system has also failed in this respect.

rlpb 12y ago
> The underlying problem is that there's no solution that's portable across init systems. He describes one that would be portable. Even upstart's SIGSTOP hack is portable across any init system that chooses to implement it; no linking to any init-system-specific library required.
- mjg59 12y ago
  His option 1 is less featureful than the protocol provided by systemd, and is also not implemented by any other init daemon. His option 2, well. No. Doing it reliably means task-specific knowledge, which means adding the same kind of complexity that init scripts are currently full of. Maintaining this knowledge in the daemon is absolutely the correct thing to do. It would obviously be preferable to have one mechanism that works across all init daemons, but since there isn't one we're stuck with the current situation. systemd's implementation is exactly as portable as upstart's hack - any OS can implement it. The relevant code is under a liberal license.
  - felixgallo 12y ago
    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).

by mjg59 12y ago

rlpb 12y ago

> The underlying problem is that there's no solution that's portable across init systems. He describes one that would be portable. Even upstart's SIGSTOP hack is portable across any init system that chooses to implement it; no linking to any init-system-specific library required.

mjg59 12y ago
His option 1 is less featureful than the protocol provided by systemd, and is also not implemented by any other init daemon. His option 2, well. No. Doing it reliably means task-specific knowledge, which means adding the same kind of complexity that init scripts are currently full of. Maintaining this knowledge in the daemon is absolutely the correct thing to do. It would obviously be preferable to have one mechanism that works across all init daemons, but since there isn't one we're stuck with the current situation. systemd's implementation is exactly as portable as upstart's hack - any OS can implement it. The relevant code is under a liberal license.
- felixgallo 12y ago
  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).