Hi all, Although all "init systems" are different, a typical "init system" functions as the first and only program called by the kernel, it spawns both one-time and respawned processes, and it facilitates shutdown: Typically with a shutdown shellscript. The part that remains PID1 after the system is up and running also reaps zombies and listens for certain other signals. To summarize:
Stage 1: Take control, and run early boot startup programs. Stage 2: Run the steady state. Perhaps respawn crashed daemons. Stage 3: Shut down. In stage 2, you're not confined to using only the Stage 2 facilities bestowed by your init system: You can run a separate process supervisor in addition to the facilities bestowed by your init system. This often has advantages. Back in the mid 00's, I discovered daemontools as something necessary to install for djbdns. Soon I began using daemontools to control my own, home grown daemons. This was a trememdous opportunity, because daemons spawned by daemontools (or runit or s6 or perp) needn't "put themselves in the background." They're just ordinary foreground programs you'd run on a terminal, with stdin and maybe stdout going to log files. EASY. Then I discovered that sometimes it's easier to make a daemon start from daemontools rather than fix a malfunctioning sysvinit init script. Init scripts typically encounter five functionalities (start, stop, restart, and a couple more I forgot). With daemontools, all you need is start. Init scripts are typically 100-200 lines: daemontools run script are typically 8. Init scripts import over 100 lines of non-obvious functions: With daemontools everything's on the surface. So I used the supplied sysvinit (and later upstart) scripts or .d's when they worked, but if they gave me trouble I couldn't solve in a few minutes, I just shut them off and ran them from daemontools instead. Life was easy, life was good. People used to say "why should I learn two systems when one will do?" I'd answer "because one system is advantageous for some things, and the other system is advantageous for others." A decade passed, daemontools is unmaintained, but served as the inspiration for daemontools-encore, runit, s6 and perp. Runit, s6 and probably perp (I've never used it) are outstanding drop-in replacements for daemontools, and they have the advantage that, if you ever decide you want to replace your whole init system, they can also function as init systems. Replacing any init system with any other init system is somewhat difficult: I've done it several times. But adding a Process Supervisor like daemontools, daemontools-encore, runit or s6 to run on top of an existing init system, is almost trivial. It's a skill every serious computer user should have: It helps you control your own destiny, and it's a spectacular simplification if you write your own daemons. If you're a DIY kind of person, try it. Put the Process Supervisor part of runit or s6 on your sysvinit-initted computer, and watch how much you start to like having a Process Supervisor. I'd go so far to say that if you run a process supervisor on top of sysvinit, you'll have *much* less incentive to consider init systems other than sysvinit. SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
