From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1611 Path: news.gmane.org!not-for-mail From: "rehan khan" Newsgroups: gmane.comp.sysutils.supervision.general Subject: RE: using runit as init Date: Thu, 10 Jan 2008 21:56:28 -0000 Message-ID: <50F2BE60A0EF6D478B1BCC633DEC28CC082B1E@server.home.internal> References: <200801032151.21524.list-supervision@augensalat.de> <200801100006.54381.list-supervision@augensalat.de> <200801091634.06623.mike@geekgene.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1200002213 21770 80.91.229.12 (10 Jan 2008 21:56:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jan 2008 21:56:53 +0000 (UTC) To: "Bernhard Graf" , Original-X-From: supervision-return-1846-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Jan 10 22:57:14 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 1JD5Ok-0001O3-7z for gcsg-supervision@gmane.org; Thu, 10 Jan 2008 22:57:14 +0100 Original-Received: (qmail 7346 invoked by uid 76); 10 Jan 2008 21:56:57 -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 7340 invoked from network); 10 Jan 2008 21:56:57 -0000 Original-X-Trace: 16686463/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: rehan.khan@dsl.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJMjhkc+8aMG/2dsb2JhbACpdQ Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: using runit as init thread-index: AchTa3kJjgrbJrShSY2XVzoVgqZ23QATpK2g Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1611 Archived-At: Starting services over and over seems odd to me too. Unfortunately I have come to believe that this is unavoidable in any supervision system without getting every project/programmer of every app that needs an init script to put in some code to support a 'wait/pause' feature. Of course this will never happen. Getting runit to do it will bloat runit beyond any usefulness. I don't believe runit is a good replacement for init because it does not solve all the challenges an init system may need to overcome. However the things that it does do it does really well. So it is a good add-on to SysV init. IMHO it is a great adjunct to any existing init and using both together provides one with an environment that is 100% backwards compatible, whilst providing service supervision and parallel startup. I can't see any compelling reasons to replace init with runit except for special cases like memory constrained systems using a dietlibc compiled runit. Many techniques have been discussed recently on the list to run services once or to wedge system init scripts into a runit environment but they are workarounds at best or kludges at worst. The best idea is to not use runit for these tasks and to continue to use init. This will save you lots of time trying to resolve issues that don't really need to be resolved (they are taken care of quite well by init). The only downside AFAIKS is that you don't get any benefit from parallelisation. On a server system this is not too great an issue but on desktop systems it is more of an issue. D-bus and haldaemon are getting a strong following especially in the Gnome world and these services tend to develop dependencies built upon them. e.g. Bluetooth, avahi, yum-updatesd, bind and others depend on d-bus and sometimes also haldaemon through d-bus on Fedora. D-bus dying breaks all these other services and re-starting d-bus does not fix them (they don't re-attach to d-bus automatically). They all have to be stopped and restarted. This is where runit falls down if you have a default installation or use execline based scripts. A runit environment needs to be wrapped in some other environment that takes proper care of dependancies (not just start-up ones but stop/restart dependancies as well) and other caretaking tasks. [ btw, d-bus is a very stable app and has not crashed in my experience so no disrespect to the d-bus developers :) ] I have come up with some of this wrapper code in the fedorafastboot project. So when a service starts up, it 'registers' itself with any dependancies it starts. If those dependancies stop for any reason their finish script stops the dependant services as well (there is no mechanism in runit to do this). What has still not been done is a proper restart. When d-bus stops and the dependant services also stop only d-bus gets restarted not the dependant services (which ideally should also be restarted). It's all very messy and overly complicated but eventually I will have all this covered somehow, hopefully in a user-transparent way where the user only has to specify the dependancies in the run script and the wrapper code does all the rest of the work. Still, I have it working in a useful way right now where if d-bus stops or crashes it will pull down any services that depend on it as well. A ctrl-alt-backspace restarts X and as X is also a supervised with a list of dependancies it restarts all the dependancies and restarts X (plus all the panel applets which depend on those services). Still a bit kooky but it does not require a reboot, just an X restart. Init still runs the iptables scripts, kudzu, wine and a couple of other (non-daemon) scripts which won't benefit from being managed by runit. Perhaps what would be most beneficial for runit long term would be to add runit's service supervision functionality natively into InitNG and/or Upstart. R -----Original Message----- From: Bernhard Graf [mailto:list-supervision@augensalat.de]=20 Sent: 10 January 2008 09:31 To: supervision@list.skarnet.org Subject: Re: using runit as init 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". > 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 -generic/initscrcomconv.html [6] http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core -generic/initsrcinstrm.html --=20 Bernhard Graf