On Sat, 4 Jun 2016 00:42:46 +0200 Florian Zieboll <f.zieb...@web.de> wrote:
> My experience with init systems is mostly limited sysV init (well, > also busybox and system d). That said, I wonder, what information any > arbitrary init system would need, that can not be delivered e.g. in a > simple XML file, packaged with the daemon. You never, never, NEVER want PID1 to be encumbered with an XML parser. Unless you're OS/x (launchd). What could *possibly* go wrong? > > Seriously, what else besides dependencies on other daemons that have > to be running and some testing for the existence of certain > (everything is) files would be necessary to pass to a parser script, > which could be packaged with the respective init system? > > Somewhat stunned, Hi Florian, You've taken this discussion deep enough that the definition of "init system" becomes relevant. Up until your question, init system discussions have pretty much divided things into the monolithically entangled April Fools Architecture systemd, and all other inits, which are fairly sane. You're going deeper. I'm going to reveal my bias right now. I think an init system should look like this: The author, Rich Felker, contends that PID1 should do nothing but fork off a shellscript (the rc file) and sit there spinning around handling signals. The rc file, which is NOT part of PID1, calls the software that handles process management or process supervision (the latter being the name we call things that respawn and don't expect the daemon to put itself in the background). I've read some of the writings of Laurent Bercot, author of s6 and s6-rc, and if I understand him right, Laurent doesn't like the Felker model because if the process handling the rc shellscript dies and there are no terminals surviving, you're left with a dead machine whose PID1 is still spinning merrily along. He's right about that, but it's not a problem I'd personally worry too much about. But then again, I'm not running a server bringing in $100K revenue a day. If you're advocating putting an XML parser in something spawned by the rc shellscript, hey, I'm fine with that. I'd do it differently, but we're talking minor differences. If you're talking about putting it in PID1, well, that's why we all deserted systemd: PID1 shouldn't have that crap. I personally think that the system of processes having provides and needs is brilliant. I don't think it's ever been executed well, but the idea is great. With provides and needs, it's probably pretty easy to figure out run order, or with the daemontools-inspired process supervisors, run script dependency checks. I think this is what you were getting at with the XML idea. There are two points of view on converting provides and needs to process order: Fixed, where it's calculated ahead of time and turned into a process startup order, and on boot, where the process starting order gets done at boot time. Poettering favors the latter. I prefer the former so that my boot is guaranteed determinate and I know the process instantiation order. Either way, as long as that stuff gets done outside of PID1, I'm happy. Now I'm going to wander into the realm of pure opinion, and please understand, I am not, not, NOT suggesting Devuan ever officially incorporate this... Regardless of your OS, regardless of your init system, regardless of your distro, you can really take charge of your computer by moving some of the process management out of your init system and into a dedicated process supervisor like daemontools-encore, runit (used as a non-PID1), and s6. Every process you move out of sysvinit or OpenRC and into something like s6 is one more 100 line init script you can ignore. It's one more set of magic order-defining comments you don't need. Before I ever heard of systemd, I was using daemontools to run some of my processes, just so I'd know what was under the hood, and I could work on them. After all, the sysvinit/upstart combination that existed before systemd wasn't all that understandable. In the early days of the systemd controversy, I thought I'd just go with systemd, and one by one remove control of processes from systemd and give them to daemontools-encore or s6. You know how old I am? My first car (1959 Plymouth that I bought for $150) had a flat head 6 engine on which you could do a tune-up in 20 minutes with a pliers, adjustable wrench, an emery board and a gapping tool. Do you know how NICE that was? I could do almost anything on that car if it didn't require a lift. I look in the engine compartment of my Jeep Patriot and know the most technical thing I'll ever do to it is fill the coolant. Everything's all interconnected. I like my Jeep's gas mileage and the fact that it doesn't burn a quart of oil every 50 miles, but man, I miss my Plymouth. The more you take your process control away from your init and hand it over to the likes of daemontools-encore, Runit or s6, the more you feel like your under the hood of a 1959 Plymouth, only this 59 Plymouth DOES get 2016 gas mileage and performance. I always feel a lot better when I can singlehandedly fix what goes wrong with my possessions. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
