From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1598 Path: news.gmane.org!not-for-mail From: "rehan khan" Newsgroups: gmane.comp.sysutils.supervision.general Subject: RE: using runit as init Date: Sat, 5 Jan 2008 07:45:57 -0000 Message-ID: <50F2BE60A0EF6D478B1BCC633DEC28CC01F708@server.home.internal> References: <200801032151.21524.list-supervision@augensalat.de> <200801031722.26992.mike@geekgene.com> <12EC84FDD73F4BD8A78E7501EB19F1E2@home.internal> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84F6F.026167EC" X-Trace: ger.gmane.org 1199519171 1317 80.91.229.12 (5 Jan 2008 07:46:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 07:46:11 +0000 (UTC) To: Original-X-From: supervision-return-1833-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Jan 05 08:46: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 1JB3jc-00084E-DD for gcsg-supervision@gmane.org; Sat, 05 Jan 2008 08:46:24 +0100 Original-Received: (qmail 1427 invoked by uid 76); 5 Jan 2008 07:46:06 -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 1417 invoked from network); 5 Jan 2008 07:46:06 -0000 Original-X-Trace: 7050711/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.31 X-SBRS: None X-RemoteIP: 62.241.162.31 X-IP-MAIL-FROM: rehan.khan@dsl.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACfEfkc+8aIf/2dsb2JhbACCb448NZhR Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: using runit as init thread-index: AchPMCLt3riOyJrBSIuPESw/cV96PwAOdpu7 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1598 Archived-At: This is a multi-part message in MIME format. ------_=_NextPart_001_01C84F6F.026167EC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You could also try the following: http://fedorafastboot.wiki.sourceforge.net/The+Runlevel+Scheme It is something I have been working on for a couple of months and is a = little rough around the edges. Mainly developed for fedora but it is = fairly generalised so I guess it can easily be ported. There are no 1, 2 = and 3 scripts as described in the runit docs. Runit is controlled by = inittab. Each runlevel change runs a runsvchdir command to a different = directory. So for each service you are monitoring you will need a = symlink for that service in the runlevel directories. You will need to = put a 'runsvdir -P runlevel1' command somewhere early in the startup - I = have it right after there is a r/w filesystem and selinux relabel or = just as the last command in rc.sysinit. so something like : runsvchdir runlevel1 runsvdir -P /var/service runlevelS can be symlinked to runlevel1 or have it's own directory. Init is still process 1 and init runlevels run as normal. No changes to = the kernel parameters are neccessary (as it is still init). The = checksrv.sh and checksrvgtk.sh (gui for x using zenity) scripts are = quite useful in seeing what services are running/stopped or failing and = they should work fine in Suse (there might be bashisms that need sorting = to get them working ok). Annvix distro has a pretty good script for = managing runit services (which works on fedora, but there are long = delays (~2-3mins at least on fedora) while it figures out if a service = is failing. The above scripts can get the status quicker although there = is a small chance it might be inaccurate (1 in every 100 times it is = run) for a failing service. The init scripts are direct ports of the fedora scripts so they might = only be helpful to you as additional examples of how to start a = particular services. I haven't done much work on the runlevel scheme as I mainly use the = incremental scheme (which gets me to a desktop fast). If you try it I = would appreciate any feedback on what works and more importantly what = doesn't. regs Rehan -----Original Message----- From: Bernhard Graf [mailto:list-supervision@augensalat.de] Sent: Sat 1/5/2008 00:15 To: supervision@list.skarnet.org Subject: Re: using runit as init =20 Mike Buland wrote: > In general, if you want to retain init-style runlevels, then you > don't want to replace SysV init. I have switched to runit entirely, > it manages every service, and it does indeed support "runlevels."=20 > See > http://smarden.org/runit/runsvchdir.8.html for details. Each runit > runlevel is really just another service directory, runsvchdir changes > which service directory you are using. the runit "init" program is > provided mainly for compatibility. > > There is no reason for runlevels to be numbered, and the kernel > offers no support for runlevels, nor do any bootloaders. When you > pass 2, 3, 4, S, etc. to the kernel, it is ignored as an unrecognized > parameter, but made available to running processes a number of ways.=20 > Runit makes the commandline as well as any variables that are set on > the kernel commandline available to the script 1 (and maybe 2 and 3, > but I use it in 1). Therefore if you set a variable in the > bootloader on the kernel commandline named "runlevel" then you can > use that in script 1 to change your runlevel. > > However, I would say based on the way you are using runit as process > 1, you would probably be better off sticking with sysvinit and adding > runsvdir to your inittab (a script very similar to the example script > 2 provided with runit is just what you want). As I wrote in my previous email I want an easy way to switch from SysV=20 init to runit (or may be another one that supports process=20 supervision). Since I have to care for a couple of production systems=20 this switch must meet some conditions: - full support for the old init system - keep manual adjusting to a minimum ATM I'm starting daemontools svscan from inttab on those hosts in=20 addition to the normal SysV init stuff. This works but is not really=20 pretty - I'd like to have a more consistent administration interface. The goal is to install runit with RPM, reboot and then link the=20 daemontools things into runit's service directory. > As for the runlevel code, I got this from this very list a long time > ago, give it a shot in script 1: > > # Set runlevel to: > # - single if kernel has param: S > # - RUNLEVELNAME if kernel has param: runlevel=3DRUNLEVELNAME > # - default if kernel has no params or unable to set requested > runlevel grep -q '\(^\| \)S\( \|$\)' /proc/cmdline && > runlevel=3D'single' runsvchdir ${runlevel:-default} || runsvchdir > default Good tip! /proc/cmdline seems a smart way. Question 1 resolved. :-) > utmp/wtmp support is done, I believe, through an external program, > check out the getty*/finish scripts that are provided with the > default distribution. utmpset only clears lines from utmp, there is no way of setting anything = as the name suggest. --=20 Bernhard Graf ------_=_NextPart_001_01C84F6F.026167EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: using runit as init

You could also try the following:

h= ttp://fedorafastboot.wiki.sourceforge.net/The+Runlevel+Scheme

It is something I have been working on for a couple of months and is a = little rough around the edges. Mainly developed for fedora but it is = fairly generalised so I guess it can easily be ported. There are no 1, 2 = and 3 scripts as described in the runit docs. Runit is controlled by = inittab. Each runlevel change runs a runsvchdir command to a different = directory. So for each service you are monitoring you will need a = symlink for that service in the runlevel directories. You will need to = put a 'runsvdir -P runlevel1' command somewhere early in the startup - I = have it right after there is a r/w filesystem and selinux relabel or = just as the last command in rc.sysinit.

so something like :

runsvchdir runlevel1
runsvdir -P /var/service

runlevelS can be symlinked to runlevel1 or have it's own directory.

 Init is still process 1 and init runlevels run as normal. No = changes to the kernel parameters are neccessary (as it is still init). = The checksrv.sh and checksrvgtk.sh (gui for x using zenity) scripts are = quite useful in seeing what services are running/stopped or failing and = they should work fine in Suse (there might be bashisms that need sorting = to get them working ok). Annvix distro has a pretty good script for = managing runit services (which works on fedora, but there are long = delays (~2-3mins at least on fedora) while it figures out if a service = is failing. The above scripts can get the status quicker although there = is a small chance it might be inaccurate (1 in every 100 times it is = run) for a failing service.

The init scripts are direct ports of the fedora scripts so they might = only be helpful to you as additional examples of how to start a = particular services.

I haven't done much work on the runlevel scheme as I mainly use the = incremental scheme (which gets me to a desktop fast). If you try it I = would appreciate any feedback on what works and more importantly what = doesn't.

regs
Rehan

-----Original Message-----
From: Bernhard Graf [mailto:list-supervision@au= gensalat.de]
Sent: Sat 1/5/2008 00:15
To: supervision@list.skarnet.org
Subject: Re: using runit as init

Mike Buland wrote:

> In general, if you want to retain init-style runlevels, then = you
> don't want to replace SysV init.  I have switched to runit = entirely,
> it manages every service, and it does indeed support = "runlevels."
> See
> http://smarden.org/ru= nit/runsvchdir.8.html for details.  Each runit
> runlevel is really just another service directory, runsvchdir = changes
> which service directory you are using.  the runit = "init" program is
> provided mainly for compatibility.
>
> There is no reason for runlevels to be numbered, and the kernel
> offers no support for runlevels, nor do any bootloaders.  When = you
> pass 2, 3, 4, S, etc. to the kernel, it is ignored as an = unrecognized
> parameter, but made available to running processes a number of = ways.
> Runit makes the commandline as well as any variables that are set = on
> the kernel commandline available to the script 1 (and maybe 2 and = 3,
> but I use it in 1).  Therefore if you set a variable in = the
> bootloader on the kernel commandline named "runlevel" = then you can
> use that in script 1 to change your runlevel.
>
> However, I would say based on the way you are using runit as = process
> 1, you would probably be better off sticking with sysvinit and = adding
> runsvdir to your inittab (a script very similar to the example = script
> 2 provided with runit is just what you want).

As I wrote in my previous email I want an easy way to switch from = SysV
init to runit (or may be another one that supports process
supervision). Since I have to care for a couple of production = systems
this switch must meet some conditions:
- full support for the old init system
- keep manual adjusting to a minimum

ATM I'm starting daemontools svscan from inttab on those hosts in
addition to the normal SysV init stuff. This works but is not really
pretty - I'd like to have a more consistent administration = interface.

The goal is to install runit with RPM, reboot and then link the
daemontools things into runit's service directory.

> As for the runlevel code, I got this from this very list a long = time
> ago, give it a shot in script 1:
>
> # Set runlevel to:
> # - single       if kernel has param: = S
> # - RUNLEVELNAME if kernel has param: runlevel=3DRUNLEVELNAME
> # - default      if kernel has no params = or unable to set requested
> runlevel grep -q '\(^\| \)S\( \|$\)' /proc/cmdline &&
> runlevel=3D'single' runsvchdir ${runlevel:-default} || = runsvchdir
> default

Good tip! /proc/cmdline seems a smart way. Question 1 resolved. :-)

> utmp/wtmp support is done, I believe, through an external = program,
> check out the getty*/finish scripts that are provided with the
> default distribution.

utmpset only clears lines from utmp, there is no way of setting = anything
as the name suggest.

--
Bernhard Graf

------_=_NextPart_001_01C84F6F.026167EC--