From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1603 Path: news.gmane.org!not-for-mail From: Bernhard Graf Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: using runit as init Date: Thu, 10 Jan 2008 00:06:54 +0100 Message-ID: <200801100006.54381.list-supervision@augensalat.de> References: <200801032151.21524.list-supervision@augensalat.de> <200801082328.06568.list-supervision@augensalat.de> <20080109020503.GX41886@linsec.ca> 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 1199920024 26283 80.91.229.12 (9 Jan 2008 23:07:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2008 23:07:04 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1838-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Jan 10 00:07:23 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 1JCk14-0008E6-S1 for gcsg-supervision@gmane.org; Thu, 10 Jan 2008 00:07:22 +0100 Original-Received: (qmail 23492 invoked by uid 76); 9 Jan 2008 23:07:05 -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 23485 invoked from network); 9 Jan 2008 23:07:05 -0000 User-Agent: KMail/1.9.1 In-Reply-To: <20080109020503.GX41886@linsec.ca> Content-Disposition: inline Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1603 Archived-At: 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/ -- Bernhard Graf