From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1605 Path: news.gmane.org!not-for-mail From: Mike Buland Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: using runit as init Date: Wed, 9 Jan 2008 16:34:06 -0700 Organization: Geek Gene Message-ID: <200801091634.06623.mike@geekgene.com> References: <200801032151.21524.list-supervision@augensalat.de> <20080109020503.GX41886@linsec.ca> <200801100006.54381.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 1199921768 31708 80.91.229.12 (9 Jan 2008 23:36:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2008 23:36:08 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1840-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Jan 10 00:36:29 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 1JCkTB-00010y-Uq for gcsg-supervision@gmane.org; Thu, 10 Jan 2008 00:36:26 +0100 Original-Received: (qmail 27451 invoked by uid 76); 9 Jan 2008 23:36:09 -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 27438 invoked from network); 9 Jan 2008 23:36:09 -0000 User-Agent: KMail/1.9.6 In-Reply-To: <200801100006.54381.list-supervision@augensalat.de> Content-Disposition: inline Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1605 Archived-At: 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 If this feels less elegent to you than "need X" you could always wrap it with another script. that would just make your scripts look prettier. Also, this has a few interesting advantages. Firstly, sv start X will wait be default for 7 seconds for the service to come up, even if it's already in the process of starting, so there are never any conflicts. If the service is already up, it returns immediately indicating success. If the service has not come up yet, or something has gone wrong, it will return non-zero and the hal script (in this example) will also exit non-zero, indicating an error and runit will retry a second or two later. This is very similar to the need method, except that in my opinion it has a few advantages, especially relating to the asynchronous nature of the way runit works. In the above example, there is no extra accounting being done, no extra programs need to be written, it is efficient, safe, and will keep trying in case there's a temporary error on either service. 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? In the former case, I can't understand why you would want the rc script to be handled by a service, you're right, you're gaining very little, and making extra work. The two ideologies are diametrically opposed, you can't really reconcile them, nor should you be able to. However, using runit as init gives you three scripts that run that let you do anything you want. When I was transitioning from SysV to Runit inits I simply called rc in script 1 and 3 and left 2 more or less alone from the reference. 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. 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. It's really the closest I can come to a cleaner hack, but really, I would go with the former option or just sack the SysV style and switch over entirely to runit, it's so much nicer and anyone can make the run scripts, most of which are only a couple lines... --Mike P.S. If you really want to go with the "down" idea, and not have a dummy service running that you can stop later, and that runit can stop automatically for you at system shutdown, etc. Then consider just adding a couple of lines such as: touch /etc/rc-compat/down sv start /etc/rc-compat into your script 1, don't put it in 2, if 2 dies it's restarted, and rc scripts shouldn't be called more than once in a row if it's avoidable. The above case will ensure there is a down file, and start the service, when the service finishes, it will not start. Be aware that this is basically the uber-complex version of just calling the rc script by hand, and really gives you nothing except concurrent execution of the rc scripts and the other runit processes, which could also be accomplished in bash with a &. On Wednesday 09 January 2008 04:06:54 pm Bernhard Graf wrote: > Vincent Danen wrote: > > Yeah, Annvix is a lot of work. =) And thank you. Execline is > > definitely nice.. using it with dietlibc for some stuff (like > > mingetty and runit itself) really keeps the overhead down. > > I've had no luck with execline and dietlibc: Got "segmentation fault" > errors that went away after building execline with glibc. > > Of course I should test this a bit further and file an error report... > > > >> That's got the relevant runit scripts we use to handle init. Note > > >> that we don't completely do away with sysvinit... there are some > > >> useful tools that come with it; we just don't use sysvinit's init. > > > > > >Actually I'm missing two essential things in runit, that would allow > > > to replace "standard" (Linux/SysV) init while keeping the > > > start/Stop scripts in the beginning: > > > > > >- possibility to set no-respawn mode for a service, instead run > > > command (e.g. "/etc/init.d/service start") when service appears in > > > runsvdir's directory and run other command (e.g. > > > "/etc/init.d/service stop) when it disappears > > > > Wasn't this addressed already? Or maybe I'm missing something? > > Can't you use the down script? I.e. you could use run to start it > > and once it exits, doesn't runit look for the down script to execute > > prior to restarting? If so, you could use a 'sv down' or something > > similar (maybe even something as simple as touching 'down') to > > prevent it from starting again, right? > > > > Of course, if you do something like that, you might need to write a > > wrapper that would remove the down file before calling 'svc up'. > > I would like to just link init scripts into runsvdir's directory, so > they are started automatically. But as we know init scripts terminate > and runsv would restart them immediately. I'd like to have a > non-respawn mode for runsv. > I think this could be realised by a wrapper that is called by runsv, > runs the SysV start script and then waits for SIGTERM. > > But maybe I'm missing something and there is already a way to achieve > this. > > > >- service dependencies > > > > We've tackled this somewhat, but Annvix has a frontend called srv > > which handles the dependencies. It's quite crude and definitely > > could use some work, but we've found there are very few things > > outside of nfs that have strict "service X needs to be up and running > > before service Y" dependencies. > > About service dependencies: There is a link on Gerrit's site to an IMHO > elegant way: [3], realised in [4]. This concept would require changing > how runsvdir starts services. > > Having all this it would be simple to convert the links in directories > /etc/init.d/rc[0123456S].d into correspondig links > in /etc/runit/runsvdir/[0123456S] and replace init-daemon-install-tools > like chkconfig or insserv by runit-compliant versions. > So no need to change all daemons with those init.d start-stop scripts. > Even those that are installed later would continue to work. > > > >Another interesting project is ninit [1] and its ancestor minit [2] > > > > > >[1] http://riemann.fmi.uni-sofia.bg/ninit/ > > >[2] http://www.fefe.de/minit/ > > > > Never looked at these. svscan is definitely useful. Do they > > supervise services as well? > > Of course they do. Those don't respawn terminated processes by default, > but can be told to do so. Supervising is done by [mn]init directly, so > there are not n supervisor processes for n supervised processes, but > only one process that usually runs at pid 1 and supervises all n > processes. > > Another interesting feature: You don't have to put an executable program > into run, instead run can be a softlink to a program and params for > this program are simply stored in a file named params. > > Instead of starting a getty in a script: > #!/bin/sh > exec /usr/bin/setsid /sbin/mingetty --noclear tty1 > > just symlink run to /usr/bin/setsid and put into params: > /sbin/mingetty > --noclear > tty1 > > Thus no shell (or any other interpreter like execline) has to be loaded. > > [mn]init doesn't poll the service directory as svscan/runsvdir do. > Can be seen as advantage, when you don't want permanent disk access. > > > [3] http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/index.html > [4] http://www.kernel.org/pub/linux/utils/util-linux/