Please find attached runit-0.13.1.ebuild and an init script for launching runsvdir. runit is a compatible version of djb's daemontools with many enhancements and the ability (not utilised in the current ebuild) to replace init. I suggest sys-apps/runit. No dependencies except glibc.] Torne
Created attachment 24291 [details] The ebuild
Created attachment 24292 [details] The init script (to go in files)
Comment on attachment 24291 [details] The ebuild Oh dear; the attachments have been base64'ed or something, by the looks of it.. trying again with firebird instead of lynx
Created attachment 24307 [details] The ebuild
Created attachment 24308 [details] The init script
Created attachment 24343 [details] A better version of the ebuild This version uses dohtml for html docs instead of dodoc, and puts the init replacement part into sbin as it can't be used by users (rest of package can be run just fine by users, so left in bin)
We used to use svc to start daemons in the scripts, but stopped due to licensing. It is however a nifty feature, and some people requires it. Can start-stop-daemon calls just be replaced, or do we need major changes to scripts to support this - I have looked at the site a few times, but have not gotten around to looking at it properly ...
It's neccecary to create valid supervision directories (really just the run script) for each service you want to run. Many services require nonstandard options when invoked from a run script instead of from start-stop-daemon; for example, it's vital that daemons do not fork and detach as this causes any supervisor (djb's daemontools or runit) to think the daemon has terminated, and thus start it again. All run scripts should be of the vague form: 'exec /path/to/daemon --run-in-foreground' ideally with minimal PATH..etc set in the script beforehand. Also, it's standard practise on supervised machines (like my current Debian-based server, soon to be replaced with a Gentoo system due to my desire for hardened-gcc compiles) to have services not log to syslog but instead to stdout where per-daemon logging can take place from a log service. It's very much a philosophy thing; running supervised daemons is a different 'flavour' to sysvinit style systems. This ebuild is designed to mix the two (runsvdir runs as a sysv style daemon but then launches supervisors); I might in the future be able to extend this ebuild to support installation as an init replacement, but then all daemons would need suitable run scripts. I suppose the daemon ebuilds could provide run scripts as well as init scripts, if people felt like writing them... (USE="supervision" perhaps?)
Created attachment 25866 [details] Update to 1.0.0, ready to replace sysvinit! # ChangeLog for sys-apps/runit # Copyright 2000-2004 Gentoo Technologies, Inc.; Distributed under the GPL v2 # $Header: $ *runit-1.0.0 (18 Feb 2004) 18 Feb 2004; Alex Efros <powerman-asdf@yandex.ru> : Updated to runit-1.0.0. Added support for all runit features (like /sbin/init replacement, runlevels, etc.). Also added example bootscripts to use with runit-init. /var/service is a symlink now, not a dir. Removed 'runsvdir.txt' (support for /etc/init.d/ and start-stop-daemon) - it's unreliable (because of many reasons explained at daemontools and runit's websites) while goal of this package it realibility. DESCRIPTION updated to author's one from website. :-) *runit-0.13.1 (18 Feb 2004) 18 Feb 2004; Alex Efros <powerman-asdf@yandex.ru> : Downloaded from http://bugs.gentoo.org/show_bug.cgi?id=39160 Ebuild submitted by Torne Wuff <torne-gentoozilla@wolfpuppy.org.uk>.
Created attachment 25869 [details] full ebuild (1.0.0) in .tgz (with files/ dir) I've uploaded before ebuild in plain text without required files/ dir just because some people here say "Ohh, it's too hard to view .tgz, please upload in plain text!"... ;-) But, because this ebuild don't have a much sense without it's files/, I will upload .tgz too. I hope this won't broke any rulez. ;-) Some notes about replacing sysvinit with runit-init. After emerge you can test it by rebooting with kernel option 'init=/sbin/runit-init'. This will not broke anything and not replace sysvinit (yet), and if you will be lucky you will get one agetty running at vc/1. After this test you can replace sysvinit manually: # mv /sbin/init /sbin/init-sysv # ln -s runit-init /sbin/init And last comment is about /sbin/rc script and /etc/init.d/* scripts. I think these script's phylosofy conflict with main Gentoo phylosofy! Really, these scripts much more suitable for booting LiveCD than reliable server with experienced admin (I don't really think Linux 'newbies' will want Gentoo and like Gentoo phylosofy - they usually want RedHat). I mean what these scripts are: - huge - complex - unreliable (maybe they reliable for first time initialization, but not for running services) - hard to use (because it's not always clear WHAT REALLY happens while booting and what variable in which file admin should change to contol boot process) - it's even hard to understand how /sbin/rc work by checking it's code - because there is too many similar functions calling each other, huge number of global variables updated from time to time in different places and not enough comments I've traced what /sbin/rc doing while sysinit/boot/shutdown system and make two simple scripts which doing same work (83 lines startup script and 40 lines shutdown script). I sure that it's MUCH MORE EASE for experienced admin to update these two small scripts than try to configure /sbin/rc using a lot of files in /etc. I've already used similar scripts on my own LFS-bases distribution for about 2.5 years on a number of servers so they are stable enough. These scripts will be installed by ebuild as /etc/runit/1.example and /etc/runit/3.example. Replacing /sbin/rc and start-stop-daemon with these my [13].example scripts and runsvdir will result in much more simple, fast and reliable work. As this time I see only one disadvantage of replacing /sbin/rc: it will be hard or even not possible to use existing /etc/init.d/* scripts because of their dependencies.
> And last comment is about /sbin/rc script and /etc/init.d/* scripts. > I think these script's phylosofy conflict with main Gentoo phylosofy! > Really, these scripts much more suitable for booting LiveCD than > reliable server with experienced admin (I don't really think Linux > 'newbies' will want Gentoo and like Gentoo phylosofy - they usually > want RedHat). Huh? > I mean what these scripts are: > - huge There are more systems, with more types of configurations out there. This is supposed to be a distro, so we need to support a few configurations out of the box. > - complex Not really. Just handles a few different setups. > - unreliable (maybe they reliable for first time initialization, but > not for running services) I think you confuse things here. They get whatever started and stopped no problem. If you have an issue with an daemon dying all the time, why don't you rather fix that daemon than blame something that was not even in action at the time? Or, why don't you suggest a way to get support integrated to make use of rinit's supervision features (if it will be more changes than just the rc-script itself)? > - hard to use (because it's not always clear WHAT REALLY happens while > booting and what variable in which file admin should change to contol > boot process) Hard to use? I am sorry, but starting/stopping/etc is much less of a pain then say getting a service to use supervision functionality in rinit for example. 90% people will know to do: /etc/init.d/foo start|stop. What is not clear? It say what it is doing? If not, why don't you file a bug for that rc-script to make it more descriptive? How difficult can it be to know what file to change? Most common settings (keyboard, fonts, etc) is in /etc/rc.conf, for the rest check in /etc/conf.d/foo. For the one or two odd ones out - guess what, they give a nice error about what to edit. > - it's even hard to understand how /sbin/rc work by checking it's code - > because there is too many similar functions calling each other, huge > number of global variables updated from time to time in different places > and not enough comments -- nosferatu tmp # grep -e '^[[:space:]]*#' /sbin/rc > bar nosferatu tmp # grep -v -e '^[[:space:]]*#' /sbin/rc > foo nosferatu tmp # wc -l foo bar 665 foo 144 bar 809 total -- Seems to be plenty of comments. As for the rest, I am sure you did not really try to figure it out. Hell, I did not get a mail from you asking to explain something. What is the real problem here? That we use sysvinit? If so, did you even notice that we just use /sbin/init, and it to get us booting. To go to single mode, etc, init is NOT EVEN CALLED. We do not have /etc/rc?.d/*, etc. We are as far from sysvinit as can get, besides just using the init.
Hi! :-) At first, I don't think this is good place for flame wars. I can continue discussing this by email, if you want. At second - I just proposed alternative, another way to boot system. Much more simple and reliable, but it require more understanding from admin about what he doing than current /etc/conf.d/ style. I don't say "this is good for all!", I just propose alternative. >> (I don't really think Linux 'newbies' will want Gentoo and like Gentoo >> phylosofy - they usually want RedHat). >Huh? Yeah. :) If someone want to manually select ALL software, configure compilation-time dependencies ($USE) and set gcc optimization options - I think many of these "users" will prefer to configure gpm's options by setting gpm's options in gpm's __command__line__ instead of trying to guess which variable they need to set in /etc/conf.d/gpm. From /etc/conf.d/ there a little step to well-known suxx named "linuxconf". :) I mean, it's always VERY BAD to have two ways to configure something! Because of many reasons. Two main reasons: 1) is software will be updated (new parameters added, for example) you should also correctly update /etc/init.d/NAME and /etc/conf.d/NAME to support these new parameters 2) more code - more bugs: software "NAME" may has own bugs, but you add to it another one piece of code ( /etc/{init,conf}.d/NAME ) which also may have bugs >> - huge > There are more systems, with more types of configurations out there. This > is supposed to be a distro, so we need to support a few configurations out > of the box. Yeah... for LiveCD. But after system is booted, it's much more ease for admin to have single file with 20-40 commands for booting system than a lot of scripts and configuration variables. Moreover, you can even GENERATE this small "boot" script using current script which will detect hardware and required commands for this hardware. >> - complex > Not really. Just handles a few different setups. 'Complex' - is something what MAY be simpler. Current Gentoo's boot scripts IS complex because they "handles a few different setups" while they should handle ONLY ONE setup - for this computer! See the difference? >> - unreliable (maybe they reliable for first time initialization, but >> not for running services) > I think you confuse things here. They get whatever started and stopped > no problem. If you have an issue with an daemon dying all the time, why > don't you rather fix that daemon than blame something that was not even > in action at the time? Because admin not always a "C guru" who able to "fix that daemon". And not every problem already has ready patches. But it's admin's task to have system running everytime, no matter fixed this daemon or not yet because... Admin should be sure what daemon will be restarted in case of any troubles. > Or, why don't you suggest a way to get support integrated to make use of > rinit's supervision features (if it will be more changes than just the > rc-script itself)? If you take a look at attached archive (with files/ dir) you will see that I've prepared init script which just execute "/sbin/rc sysinit", then "/sbin/rc boot" and so on - only difference is what "/sbin/rc *" is executed from /etc/runit/1 script instead of /etc/inittab. My script to "replace /sbin/rc" also installed, but as "/etc/runit/1.example", because I understand what my "simple" script will perfectly boot only my server. > Hard to use? I am sorry, but starting/stopping/etc is much less of a pain > then say getting a service to use supervision functionality in rinit for > example. 90% people will know to do: /etc/init.d/foo start|stop. 90% of people may use RedHat et friends. Did you hear term "target group of users"? Why don't make Gentoo looks like Windows by default? People who want "Start" button and "/etc/init.d/foo start|stop" and don't bother about automatical daemon restart if it die -- these people will not like to spend a lot of hours to tune and compile Gentoo! > nosferatu tmp # grep -e '^[[:space:]]*#' /sbin/rc > bar > nosferatu tmp # grep -v -e '^[[:space:]]*#' /sbin/rc > foo > nosferatu tmp # wc -l foo bar > 665 foo > 144 bar > 809 total Hehehe.... :-) It's not really fair! You should add this: $ wc -l /sbin/functions.sh /lib/rcscripts/sh/rc-daemon.sh \ /lib/rcscripts/sh/rc-services.sh /etc/init.d/halt.sh \ /etc/init.d/reboot.sh /etc/runlevels/boot/* 819 /sbin/functions.sh 398 /lib/rcscripts/sh/rc-daemon.sh 698 /lib/rcscripts/sh/rc-services.sh 198 /etc/init.d/halt.sh 7 /etc/init.d/reboot.sh 108 /etc/runlevels/boot/bootmisc 214 /etc/runlevels/boot/checkfs 105 /etc/runlevels/boot/checkroot 100 /etc/runlevels/boot/clock 92 /etc/runlevels/boot/consolefont 63 /etc/runlevels/boot/hostname 55 /etc/runlevels/boot/keymaps 59 /etc/runlevels/boot/localmount 127 /etc/runlevels/boot/modules 20 /etc/runlevels/boot/net.lo 19 /etc/runlevels/boot/rmnologin 64 /etc/runlevels/boot/serial 37 /etc/runlevels/boot/urandom 3183 total And now, compare to my boot/shutdown scripts with same functionality: $ grep -e '^[[:space:]]*#' /etc/runit/{1,2,3,ctrlaltdel} >bar $ grep -v -e '^[[:space:]]*#' /etc/runit/{1,2,3,ctrlaltdel} >foo $ wc -l bar foo 17 bar 123 foo 140 total > What is the real problem here? That we use sysvinit? If so, did you even > notice that we just use /sbin/init, and it to get us booting. To go to > single mode, etc, init is NOT EVEN CALLED. We do not have /etc/rc?.d/*, > etc. We are as far from sysvinit as can get, besides just using the init. No, I don't bother about sysvinit. The real problem is: *************************************************************** ***** ALL services MUST !!! be reliable restarted if died ***** *************************************************************** and there is ONLY ONE reliable way to restart services: - every daemon should be running under control of "superviser" (it may be DJB's "supervise" or "runsv" from runit or other software like these) - these "supervisors" itself should be reliable restarted if died, this mean they should be running by supersuperviser (like DJB's "svscan" or "runsvdir" from runit) - supersuperviser also should be restarted if died, this mean it should be executed with "respawn"-like sheme by /sbin/init. With this way, while /sbin/init is running all services will be guarantied to restart. If unthinkable happens :) and /sbin/init die ... then kernel will reboot system in any case. I've used runit-init instead of sysvinit just because it's simpler and because of this should work better. Replacing sysvinit is optional, you can have same reliability using "respawn" in sysvinit to execute "svscan" or "runsvdir". WBR, Alex. P.S. There second "real problem": simple software usually work much better than complex, so to have less bugs we should use as simple software as possible to satisfy our needs. Runit-init simpler than sysvinit. And my init scripts are simpler than /sbin/rc et friends. :)
Created attachment 33379 [details] Runit 1.0.3 ebuild Update to runit 1.0.3. Add more getties to match default /etc/inittab.
Alex's philosophy is all very well, but the scripts provided are inflexible and will work only on a few machines. If sysadmins want a minimal startup, they should write their own; every machine is different. The baselayout rc script does a good job of dealing with diverse configurations; my ebuild uses it.
Okay, uhm, it was 1.0.2 when I uploaded it in fact. However it does work for 1.0.3 without any changes, now that 1.0.3 actually exists. =)
Would it be possible to get a runit ebuild added to CVS that doesn't try to solve the "init replacement" problem? I just want a good supervisor program and I prefer runit to daemontools across various platforms because of the licensing issues. Perhaps the package could be split; Debian has a a runit and runit-init package. I don't want the runit install to touch my init anyway. Of course, I can download the ebuild here, or just build myself, but that's not the point. It just seems time to get runit integrated into Gentoo proper.
This ebuild does not replace init - it installs /sbin/runit-init as, well, /sbin/runit-init. Unless you manually replace the init binary or boot with init=/sbin/runit-init (which is what I do), then you can just use runit as a regular service. One of the attachments on this bug is a suitable init script to run it from the regular Gentoo rc scripts. You can just ignore or delete the scripts related to using it as init (/etc/runit/{1,2,3,crtlaltdel}) and use it as you want.
Works without changes for 1.0.4
added to portage if you wish to use this as a base-layout replacement, that's an exercise left up to the user
