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?
Can someone please enlighten me?
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.
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?
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.
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?
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.
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.