If you look around you should still be able to find Luke Mewburn's paper on #MewburnRC .
Similarly, what Linux people erroneously call "sysvinit" is actually van Smoorenburg init+rc created (by Miquel van Smoorenburg) for Minix in 1992.
It's not from #Unix System 5 at all, as that had obsoleted R3's init+rc system years before 1992 and gone on to the AIX SRC, and the SAF, SAC, ttymon, SMF, and stuff still in #Illumos today.
Don't use rc.local. It has been obsolete since 1983. #FreeBSD has actually discontinued it twice in its history.
FreeBSD has had Mewburn rc for most of this century. It's what #NetBSD uses and #OpenBSD has a similar but NIH system. At minimum, use Mewburn rc scripts.
http://jdebp.info/FGA/rc.local-is-history.html
The rc(8) manual page has an example script. There's tutorial doco as well.
@lobocode Oh, I'm not strictly against replacing #mewburnrc by something NOT relying on shell scripting, possibly integrated with #init. That probably makes sense.
The thing is, I still have the strong feeling that #systemd is "doing it wrong".
Regarding the "multitasking power" argument, I don't think that's directly tied here, you *could* solve this with scripting as well. Instead of just deducing an order (like mewburnrc does), you "just" need a real dependency graph.
But of course, moving away from shell scripting has the potential to give both better reliability and performance. But then, please take the time for a design of some portable, unintrusive and standardized interface between daemons and init systems 😉
@lobocode On the one hand, #FreeBSD never suffered the brokenness of #sysvinit. It uses a minimalistic init with a quite well-designed rc-system: #mewburnrc. Sure that's still based on shell-scripting, but at least it comes with a sane framework making your typical init-script short, maintainable and correct.
On the *other* hand, at least for me, whenever I have to deal with #systemd, it feels ill-designed.
Just a little example, I recently wrote quite a few daemons. There's a simple "interface" allowing an init-system to know when a daemon is really "up", exactly when its first (parent) process exits with a successful exit code. With systemd, the default mode of operation is "don't care" (started and not died yet is good enough), and if you want to inform systemd when the service is ready, the recommendation is to implement some systemd-specific startup notification API. No, thanks.
JdeBP
Felix Palmen 📯