5 ms·

Active in this industry for several decades, and I've yet to hear a convincing argument why kitchen-sink init systems are somehow an improvement over rc.d. Can

Active in this industry for several decades, and I've yet to hear a convincing argument why kitchen-sink init systems are somehow an improvement over rc.d. Can someone please enlighten me?

geocar 11y ago
http://cr.yp.to/daemontools/faq/create.html http://cr.yp.to/daemontools/faq/create.html
- vox_mollis 11y ago
  Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is sufficient cause to reinvent init? Even if djb's /service claims makes sense, it still doesn't support the significantly expanded scope of, say, systemd. I mean, hijacking system logging? What could possibly justify doing that in an init system?
  - otabdeveloper 11y ago
    > I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
  - jononor 11y ago
    systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
  - geocar 11y ago
    Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.
oofabz 11y ago
There are race conditions in rc.d. Like most concurrency bugs, they are rare, but we shouldn't ignore them. Consider what happens if you start a process, and then stop it before its pidfile gets written. Or, if you start a process that takes a while to initialize, and during that time you can't kill it normally. Now imagine combining these situations with auto-restarting daemons that crash, or shutting down a computer immediately after it boots. The right thing to do in these situations is to block until the daemon gets into its normal run state, when its PID is known and you can kill it safely. rc.d init systems don't do this, they just fire off a signal to a PID and hope for the best. It doesn't always work and on top of that, it's easy to misconfigure something, like a pidfile path or permissions.
- msbarnett 11y ago
  > There are race conditions in rc.d. Like most concurrency bugs, they are rare, but we shouldn't ignore them. Doesn't systemd have roughly the same problem, with non-deterministic boot order and dependency heuristics resulting in opaque, hard-to-debug ordering issues that appear only intermittently?
  - aidenn0 11y ago
    Any parallel init system will have non-deterministic boot order. This is very different from race conditions. Non-deterministic boot order makes bugs in your dependency system very hard to track down. Some parallel build tools have options to do a non-parallel build, but randomize the order of dependencies. This can help track down failures due to improper dependencies regardless of parallelism available. Race conditions are themselves bugs.
    - ausjke 11y ago
      I wish the various rc.d/* scripts can support real dependency, i.e. I can optionally designate S50 will not start running until S49 is completed, this is useful sometimes.
      - 11y ago

Active in this industry for several decades, and I've yet to hear a convincing argument why kitchen-sink init systems are somehow an improvement over rc.d. Can someone please enlighten me?

geocar 11y ago

http://cr.yp.to/daemontools/faq/create.html http://cr.yp.to/daemontools/faq/create.html

vox_mollis 11y ago
Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is sufficient cause to reinvent init? Even if djb's /service claims makes sense, it still doesn't support the significantly expanded scope of, say, systemd. I mean, hijacking system logging? What could possibly justify doing that in an init system?
- otabdeveloper 11y ago
  > I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
- jononor 11y ago
  systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
- geocar 11y ago
  Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.

oofabz 11y ago

There are race conditions in rc.d. Like most concurrency bugs, they are rare, but we shouldn't ignore them. Consider what happens if you start a process, and then stop it before its pidfile gets written. Or, if you start a process that takes a while to initialize, and during that time you can't kill it normally. Now imagine combining these situations with auto-restarting daemons that crash, or shutting down a computer immediately after it boots. The right thing to do in these situations is to block until the daemon gets into its normal run state, when its PID is known and you can kill it safely. rc.d init systems don't do this, they just fire off a signal to a PID and hope for the best. It doesn't always work and on top of that, it's easy to misconfigure something, like a pidfile path or permissions.

msbarnett 11y ago
> There are race conditions in rc.d. Like most concurrency bugs, they are rare, but we shouldn't ignore them. Doesn't systemd have roughly the same problem, with non-deterministic boot order and dependency heuristics resulting in opaque, hard-to-debug ordering issues that appear only intermittently?
- aidenn0 11y ago
  Any parallel init system will have non-deterministic boot order. This is very different from race conditions. Non-deterministic boot order makes bugs in your dependency system very hard to track down. Some parallel build tools have options to do a non-parallel build, but randomize the order of dependencies. This can help track down failures due to improper dependencies regardless of parallelism available. Race conditions are themselves bugs.
  - ausjke 11y ago
    I wish the various rc.d/* scripts can support real dependency, i.e. I can optionally designate S50 will not start running until S49 is completed, this is useful sometimes.
    - 11y ago