On Fri, 2 Jan 2015 01:31:46 +0100 toki clover <[email protected]> wrote:
> ---------- Forwarded message ---------- > From: toki clover <[email protected]> > Date: 2015-01-02 1:30 GMT+01:00 > Subject: Re: Using runit-init on debian/Jessie in place of > sysvinit/systemd To: Luke Diamand <[email protected]> > > > First, it's a bit crazy to use runit for init+service management > entirely because: Doesn't seem a bit crazy to me. > > - It's completely crazy to supervise every service because; first, > every service > won't fit in if it's not a daemon; I'm not sure what the preceding means, but runit is like daemontools, your run script runs the desired program in the foreground. If you mean that it's difficult to fit run-once scripts into stage 2, there are ways to make that possible. > second supervising every daemon is > dangerous. Why? And if there are some daemons you'd rather leave crashed than respawn, have one stage 2 service that runs all of them, leaves a sentinel file to prevent it from reruning those daemons, sleeps, and returns 0. So that service gets rerun every what, minute, hour, whatever (according to the sleep value), but the sentinal file prevents it from running those daemons again. Stage 3 deletes the sentinel file. > - Second, runit (or s6 for that matter) lack any decent service > dependency, actually both completely ignore the problem (athough s6 > may change this in in a near futur.) http://smarden.org/runit/faq.html#depends > - Third, do not forget the overhead of supervision (an extra instance > per daemon.) How many daemons are you planning on running? Most of the daemons running on typical desktop distros are edge-case CYA that can be lived without, and that's probably an improvement. > > Second, stuffing stage 1 `/etc/runit/1' is a bad idea because stage 1 > is very > sensible... any service that hangs in the foreground will hang booting > because C-ALT-DEL signal is inactive (see this page for more details > http://forums.gentoo.org/viewtopic-t-998478-start-25.html). How many scripts/programs/adjustments do you need to make as the computer boots up? Much of the stuff typical distros run is fluff that someone with the smarts to replace an init doesn't need. > > So, I would recommend using rc, or even better OpenRC (which is > available in Debian based OS) to take care of service dependencies > management and use service supervision for agetty (and sshd and the > likes if necessary.) (There is a complete solution with runit+OpenRC > in that thread.) runit->OpenRC was pretty easy for me to do in the OpenRC edition of Manjaro. Put: /usr/bin/openrc sysinit /usr/bin/openrc boot /usr/bin/openrc default in /etc/runit/1 And of course, you need to have runit manage your ttys because OpenRC can't respawn. As I remember (I later switched to pure runit and didn't document the hybrid extensively), you need to jump through some mild hoops if you want it to shut down elegantly, but it worked just fine without the elegance. > > That forums thread has a dangerous implementation with a stuffed > stage 1 which I split to have only sysinit related services in it and > then use stage 2 > to fully boot the system and brings it to a desired runlevel. This is > far more > safer because a tty will be available to fix anything broken if need > be. > > Stuffing stage 1 is suicidal... Two characterizations in the preceding five word sentence, "stuffing" and "suicidal". As far as stuffing, you can have more or less calls in /etc/runit/1, but as long as they're trustworthy, what's the problem? Half of them are simple shellscripts anyway: You put your daemons in stage 2. Nobody wants everything plus the kitchen sink in stage 1, but I see nothing wrong with a short shellscript to bring up udev, a short script with ip commands to bring up your network, and if necessary a short shellscript to bring up devfs (and my shellscript for that purpose was excessively long, but it can be carved to size). As far as "suicidal", I'd comment that System Rescue CD is standard suicide prevention. If, while first configuring things, you happened to get it wrong, you can boot SysRescueCD and undo your last act. Better yet, in parallel, set up an Epoch init or a sysvinit->OpenRC init so that if your runit init continually goes south, you can boot the alt-init and fix the problem. I wouldn't characterize pure runit as "crazy", I'd characterize it as a solution that fits many needs and use cases. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance
