From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1610 Path: news.gmane.org!not-for-mail From: Mike Buland Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: using runit as init Date: Thu, 10 Jan 2008 13:06:24 -0700 Organization: Geek Gene Message-ID: <200801101306.24837.mike@geekgene.com> References: <200801032151.21524.list-supervision@augensalat.de> <200801091634.06623.mike@geekgene.com> <200801101020.51580.list-supervision@augensalat.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1199995706 31148 80.91.229.12 (10 Jan 2008 20:08:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jan 2008 20:08:26 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1845-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Jan 10 21:08:46 2008 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1JD3hk-0002kB-R8 for gcsg-supervision@gmane.org; Thu, 10 Jan 2008 21:08:44 +0100 Original-Received: (qmail 25346 invoked by uid 76); 10 Jan 2008 20:08:27 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 25339 invoked from network); 10 Jan 2008 20:08:26 -0000 User-Agent: KMail/1.9.6 In-Reply-To: <200801101020.51580.list-supervision@augensalat.de> Content-Disposition: inline Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1610 Archived-At: On Thursday 10 January 2008 02:20:51 am Bernhard Graf wrote: > On Thursday 10 January 2008 00:34, Mike Buland wrote: > > Regaurding service dependancies, Richard Gooch's method is actually > > unnecesarry in a sytem such as runit, and service dependancy is > > already handled in an almost identicle way, but with less system > > overhead. > > > > At the begining of a run script just start the services you depend > > on, and exit if the sv command returns non-zero. I.e. from hal's run > > script: sv start /etc/service/dbus || exit 1 > > I tend to object: > > You mean starting a bunch of programs over and over again, because many > of them quit immediatly is less system overhead than starting programs > that pause until those programs they depend on are started? > > Also imagine one service A that depends on service B, C and D. You have > to put the checks for availability of B, C, D into A's run script. > In a complex system more services depend on B, C and D and probably > others. You have to put the same checks (and others) in all those > services. Also those checks tend to be more complicated than just saying > "need B C D". I'm honestly not sure how your need solution covers these mysterious more complicated, but you're just using need in your example below, so... Anyway, need will not block forever, it needs to do a number of different things periodically to ensure that the service has not gone into an unexpected state, etc, etc. Starting a script once every seven seconds, as I mentioned, or at a larger interval, as you suggested, I do not feel is significant system overhead. If you're using bash, bash will be using about 2 megs of memory (on my machine), most of which is actually shared libraries, and not overhead for bash (libc, ncurses, libreadline, libhistory, etc), and no cpu time for that seven seconds (or more). This is so little cpu usage that even on the oldest machines I've run runit on it doesn't even register as a single ms of cpu usage, if your desktop/server is worse...then stick with init, I guess... Yes, for me, that is completely acceptable. I don't agree that the overhead is necessarily any larger when restarting bash (cached exe image, fast startup times, and most of the "wasted memory" isn't actually wasted) compared to a need script running forever. And frankly, I like the opportunity to do other things periodically when the script may fail a dependency check, such as taking it down if it has failed for too long, or clearing out a cache file that may have gotten in the way, an errant pid file, etc, etc, etc. These are things that you cannot do with a need script. Bottom line, the runit method is more flexible, and even if it uses more resources, it's fine by me (and it's still much less than traditional rc). > > > As far as running SysV init style scripts, usually handled on modern > > linux systems (redhat, slackware, debian, etc) by the master rc > > script, are you suggesting that rc, to control runlevel changes be > > placed in it's own service, or that each SysV "service" gets it's own > > runit service? > > The latter. > > > If you're referring to the later case, you'll need to do a lot more > > work to synchronize the rc scripts and the runit services, I can't > > imagine how just making symlinks between the init.d runlevel > > directories and runsvdir service directories will actually work. > > In current distributions (hopefully) an init.d script is configured > using a program that sets the appropriate symlinks. The information for > run levels and dependencies are taken from the init scripts [5], [6]. > > If you'd replace init by runit, you had to replace those installtion > programs as well. > > This installer would install the example from [5] as: > > # ls -l /etc/runit/sv/lsb-ourdb > -rw------- 1 root root 0 Jan 10 09:00 initd > -rw------- 1 root root 30 Jan 10 09:00 need > lrwxrwxrwx 1 root root 19 Jan 10 09:00 run -> /etc/init.d/lsb-ourdb > # cat /etc/runit/sv/lsb-ourdb/need > $local_fs > $network > $remote_fs > # ls -l /etc/runit/runsvdir/2/lsb-ourdb > lrwxrwxrwx 1 root root 19 Jan 10 09:00 > /etc/runit/runsvdir/2/lsb-ourdb -> /etc/runit/sv/lsb-ourdb # ls -l > /etc/runit/runsvdir/3/lsb-ourdb > lrwxrwxrwx 1 root root 19 Jan 10 09:00 > /etc/runit/runsvdir/3/lsb-ourdb -> /etc/runit/sv/lsb-ourdb # ls -l > /etc/runit/runsvdir/4/lsb-ourdb > lrwxrwxrwx 1 root root 19 Jan 10 09:00 > /etc/runit/runsvdir/4/lsb-ourdb -> /etc/runit/sv/lsb-ourdb # ls -l > /etc/runit/runsvdir/5/lsb-ourdb > lrwxrwxrwx 1 root root 19 Jan 10 09:00 > /etc/runit/runsvdir/5/lsb-ourdb -> /etc/runit/sv/lsb-ourdb > > File initd is a flag for runit to run the script with argument "start" > first, then wait for SIGINT and run the script with argument "stop". > > File need contains services that runit has to be started first. > "$service" for "meta services" as set with "provide" in Gooch's concept. > > > Finally, if you really do want to start an rc script and make it > > appear as though it were a normal runit system service, then I would > > reccomend starting it in a run script, then executing a command that > > blocks forever. The service will use effectively no CPU time, but > > will stay running, forever. Then you can call the corrisponding rc 6 > > or whatever you want in the finish script of the service. > > I will try this, and see how far I get... > > > [5] > http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-ge >neric/initscrcomconv.html [6] > http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-ge >neric/initsrcinstrm.html I'm not actually going to pursue this. My opinion, and I know I'm not alone, is that you should really let runit run the rc script and let the normal init scripts do the only thing they're mediocre at, or switch over completely to runit and drop the lsb/rc/sysv style. Honestly, for someone who is self-professed "lazy" you're going through a lot of unnecessary work to hack a broken system into a nice one and lose all of the things except the cli that runit provides. You won't actually gain nice script supervision this way, you won't be able to tell which services are really up or not except by testing the normal init status functions of the old init scripts, you will be able to "start" and "stop" the scripts, but it doesn't buy you anything useful. Honestly, I was against sysvinit/rc style boot scripts for a number of reasons. They're a pain to write and maintain, they offer no guarantees, there's an amazing library of bash scripts with every distro that *try* to sotra find programs that have been disowned completely, and there are no guarantees in that. I wouldn't want a system that hacked init scripts into runit services to become popular, because it doesn't add anything, and it makes runit look bad. Runit is a wonderful new (in that not many people have seen the light yet) system that addresses many, many problems with other init systems and service systems. I have seen several software packages that were absolutely brilliant die before their time because of improper use making them "look bad," and I don't want that to happen to runit. If what you come up with really helps and is a definite improvement in doing things the runit way, then I applaud you, and if what you work on in the meantime works for you, then great, I'm very happy for you, but I'm not going to argue the point, I just hope that it doesn't wind up like so many marriages of technology and bringing out the worst in both parent systems. --Mike P.S. I'm not trying to start a flame war or anything, I just really like runit, and don't want to see it fall into disuse due to misconceptions about how it works. The beuty of it, the simplicty, and the assurances it provides are all thrown out the window by having the runit scritps start and disown processes of their own, then try to hunt them down later. Please at least consider it. I won't pontificate at you again ;)