using runit as init

using runit as init

[Bernhard Graf]

Hi list, happy new year!

I'm playing a little with runit as replacement for SysV init as roughly 
described in http://smarden.org/runit/replaceinit.html .

I adjusted the three runit stage scripts to play with an OpenSUSE 10.3 
Linux system. So far runit only supervises the (min)gettys, whereas all 
services that come with the distribution are still managed 
from /etc/init/rc that gets executed at the end of /etc/runit/1 .
The whole thing is wrapped into two RPMs (runit and 
runit-sysvinit-compat) that replace the sysvinit RPM installation.

Seems to work quite well, provided that I didn't do much more testing 
than boot, reboot, halt for now.

What worries me now is a smooth transition for running systems from init 
to runit.

In general I'd prefer to leave most service where they are, and just 
supervise certain ones, e.g. ssh, web server, all the djb s/w and 
custom daemons like FastCGI processes.

The problem is that runit makes (nearly) no effort to support a system 
with supervised and "traditional" non-supervised daemons.
Perhaps this is also the reason why runit didn't gain much attention in 
all the years, because concept and code are very well done AFAICT.

At the moment I'm struggling with these questions:

- A way to boot into a certain runlevel (say "init xxx" at boot prompt).
  runit and runit-init don't care about these, where as (Smoorenburg's)
  init passes the current runlevel in environment variable RUNLEVEL.
- Changing runlevels. There is no way to say "init 3" anymore.
  runsvchdir doesn't care about the SysV init scripts that are started
  in /etc/runit/1.
  runit-init only supports SysV init args "0" and "6" when not runing as
  process 1.
- utmp/wtmp support is missing completely, besides utmpset which should
  be named utmpclr or so.

Maybe somebody can give some advice or can share some example code or 
ideas.

In case of interest and if someone has some public space at hand I would 
upload the SRPMs.
-- 
Bernhard Graf

Re: using runit as init

[Mike Buland]

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/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.  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 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=RUNLEVELNAME
# - default      if kernel has no params or unable to set requested runlevel
grep -q '\(^\| \)S\( \|$\)' /proc/cmdline && runlevel='single'
runsvchdir ${runlevel:-default} || runsvchdir default

This wored great for me, then in grub I added "runlevel=X" 
or "runlevel=console"

And finally, you want the normal setup, but point /var/service 
to /etc/runit/runsvdir/current, if it's not there, it will be created when 
runsvchdir is called, or you can create it yourself, it's a symlink to the 
current service directory.  Each directory in  /etc/runit/runsvdir is a 
complete (and normal) service directory.

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

--Mike

On Thursday 03 January 2008 01:51:21 pm Bernhard Graf wrote:
> Hi list, happy new year!
>
> I'm playing a little with runit as replacement for SysV init as roughly
> described in http://smarden.org/runit/replaceinit.html .
>
> I adjusted the three runit stage scripts to play with an OpenSUSE 10.3
> Linux system. So far runit only supervises the (min)gettys, whereas all
> services that come with the distribution are still managed
> from /etc/init/rc that gets executed at the end of /etc/runit/1 .
> The whole thing is wrapped into two RPMs (runit and
> runit-sysvinit-compat) that replace the sysvinit RPM installation.
>
> Seems to work quite well, provided that I didn't do much more testing
> than boot, reboot, halt for now.
>
> What worries me now is a smooth transition for running systems from init
> to runit.
>
> In general I'd prefer to leave most service where they are, and just
> supervise certain ones, e.g. ssh, web server, all the djb s/w and
> custom daemons like FastCGI processes.
>
> The problem is that runit makes (nearly) no effort to support a system
> with supervised and "traditional" non-supervised daemons.
> Perhaps this is also the reason why runit didn't gain much attention in
> all the years, because concept and code are very well done AFAICT.
>
> At the moment I'm struggling with these questions:
>
> - A way to boot into a certain runlevel (say "init xxx" at boot prompt).
>   runit and runit-init don't care about these, where as (Smoorenburg's)
>   init passes the current runlevel in environment variable RUNLEVEL.
> - Changing runlevels. There is no way to say "init 3" anymore.
>   runsvchdir doesn't care about the SysV init scripts that are started
>   in /etc/runit/1.
>   runit-init only supports SysV init args "0" and "6" when not runing as
>   process 1.
> - utmp/wtmp support is missing completely, besides utmpset which should
>   be named utmpclr or so.
>
> Maybe somebody can give some advice or can share some example code or
> ideas.
>
> In case of interest and if someone has some public space at hand I would
> upload the SRPMs.

Re: using runit as init

[Bernhard Graf]

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/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. 
> 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=RUNLEVELNAME
> # - default      if kernel has no params or unable to set requested
> runlevel grep -q '\(^\| \)S\( \|$\)' /proc/cmdline &&
> runlevel='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

RE: using runit as init

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 5073 bytes --]


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
 
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/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. 
> 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=RUNLEVELNAME
> # - default      if kernel has no params or unable to set requested
> runlevel grep -q '\(^\| \)S\( \|$\)' /proc/cmdline &&
> runlevel='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





[-- Attachment #2: Type: text/html, Size: 6225 bytes --]

Re: using runit as init

[Bernhard Graf]

rehan khan wrote:

> You could also try the following:
>
> http://fedorafastboot.wiki.sourceforge.net/The+Runlevel+Scheme

Thanks for the pointer.
I'm checking all related sites and fedorafastboot was one of the first 
that I looked at. Has some nice infos and inspirations.

-- 
Bernhard Graf

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

* Bernhard Graf <list-supervision@augensalat.de> [2008-01-06 00:17:51 +0100]:

>rehan khan wrote:
>
>> You could also try the following:
>>
>> http://fedorafastboot.wiki.sourceforge.net/The+Runlevel+Scheme
>
>Thanks for the pointer.
>I'm checking all related sites and fedorafastboot was one of the first 
>that I looked at. Has some nice infos and inspirations.

You may also be interested in what Annvix has done.  Annvix has used
runit for init for quite a few years now, and very successfully.  It
still handles traditional "initscripts", but doesn't handle number-based
runlevels or runlevel switching (largely due to the fact that Annvix has
no GUI and thus has no real need for that).

But the /sbin/rc script is completely custom, as are the 1, 2, and 3
scripts (using execline).  There's no real documentation for anything,
but (I hope) the code is clean enough to be understandable:

http://svn.annvix.org/cgi-bin/viewvc.cgi/tools/runit/trunk/

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.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: using runit as init

[Bernhard Graf]

Vincent Danen wrote:

> You may also be interested in what Annvix has done.  Annvix has used
> runit for init for quite a few years now, and very successfully.  It
> still handles traditional "initscripts", but doesn't handle
> number-based runlevels or runlevel switching (largely due to the fact
> that Annvix has no GUI and thus has no real need for that).

Of course I also discovered Annvix already. Nice work (and a lot of, I 
suppose). Brought me to execline among other things, which I knew for 
quite some time, but never actually used so far.

> 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
- service dependencies

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/

Those have dependencies and can start services w/o respawn, but they 
don't have a svscan-like function, they can start dependend services at 
start-up - later services must be brought up and down by [mn]svc 
command. Potentially this would fit better into an existing SysV-based
init scheme, because "/etc/init.d/service start" would just execute 
[mn]svc -u service and "/etc/init.d/service stop" [mn]svc -d service.

Still runit is much more elegant IMHO by starting and removing services 
as they appear and disappear - this would make runlevels really easy.
-- 
Bernhard Graf

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

* Bernhard Graf <list-supervision@augensalat.de> [2008-01-08 23:28:06 +0100]:

>Vincent Danen wrote:
>
>> You may also be interested in what Annvix has done.  Annvix has used
>> runit for init for quite a few years now, and very successfully.  It
>> still handles traditional "initscripts", but doesn't handle
>> number-based runlevels or runlevel switching (largely due to the fact
>> that Annvix has no GUI and thus has no real need for that).
>
>Of course I also discovered Annvix already. Nice work (and a lot of, I 
>suppose). Brought me to execline among other things, which I knew for 
>quite some time, but never actually used so far.

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.

>> 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'.

>- 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.

>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/
>
>Those have dependencies and can start services w/o respawn, but they 
>don't have a svscan-like function, they can start dependend services at 
>start-up - later services must be brought up and down by [mn]svc 
>command. Potentially this would fit better into an existing SysV-based
>init scheme, because "/etc/init.d/service start" would just execute 
>[mn]svc -u service and "/etc/init.d/service stop" [mn]svc -d service.

Never looked at these.  svscan is definitely useful.  Do they supervise
services as well?

>Still runit is much more elegant IMHO by starting and removing services 
>as they appear and disappear - this would make runlevels really easy.

For me, I'm satisfied with runit -- it does the job and it does it
extremely well.  We've been using it as the defacto init system on
Annvix for quite a few years and I can't see that changing anytime soon.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: using runit as init

[Bernhard Graf]

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

Re: using runit as init

[Mike Buland]

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/

Re: using runit as init

[KORN Andras]

On Thu, Jan 10, 2008 at 12:06:54AM +0100, Bernhard Graf wrote:

> 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.

So have your script remove the symlink to the directory that contains it
from /service before it exits (or in ./finish).

> 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.

I think this is a misguided attempt to provide "uniformity". Traditional
initscript are quite horrible; I invite you to read, for example, Ubuntu's
apache2 initscript and be appalled at all the unnecessary complexity and
race conditions galore.

One of the chief motivations for switching away from an init-like system,
where services daemonise, to a runit-like system where they are supervised
by their parent process is, or at least should be, the desire to get away
from those race conditions and the fragility of it all. To get away from pid
lotto.

What reason would justify importing that mess into this clean new service
supervision and system startup scheme?

FWIW, services with initscripts you haven't converted to runit services
naturally continue to work. You can just do "/etc/init.d/foo start" even if
your process 1 is runit. Runit can even start these services automatically.
You can even arrange for them to be started and stopped on runlevel changes
(runsvchdir's) with the help of some kludgery (e.g. like the one I suggested
above).

The real solution, however, is of course to convert the messy and complex
initscripts into neat and clean run scripts. You only need to do this once
per daemon, not once per daemon per computer. Chances are someone already
has a run script for your daemon, so you needn't really do anything at all.

Why would you want to keep initscripts around to the extent of creating
one-shot runit services? Maybe there is a different solution.

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
           If at first you don't succeed, you must be a programmer.

Re: using runit as init

[Charlie Brady]

On Wed, 9 Jan 2008, Mike Buland wrote:

> 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.

For instance, compile:

main()
{
    pause();
}

into /usr/local/bin/pause, and then have a run script:

#! /bin/sh
do_something_you_care_about
exec /usr/local/bin/pause

Re: using runit as init

[Bernhard Graf]

KORN Andras wrote:

> > 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.
>
> So have your script remove the symlink to the directory that contains
> it from /service before it exits (or in ./finish).

In the sense of self-modifying code? No, thanks!

> > 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.
>
> I think this is a misguided attempt to provide "uniformity".
> Traditional initscript are quite horrible; I invite you to read, for
> example, Ubuntu's apache2 initscript and be appalled at all the
> unnecessary complexity and race conditions galore.

I'm not advocating init scripts. Compared to daemontools scripts they 
really suck. As I already wrote several times I'm looking for a way to 
replace traditional init by something than *can* supervise but also 
handles the old init scripts correctly.

> One of the chief motivations for switching away from an init-like
> system, where services daemonise, to a runit-like system where they
> are supervised by their parent process is, or at least should be, the
> desire to get away from those race conditions and the fragility of it
> all. To get away from pid lotto.
>
> What reason would justify importing that mess into this clean new
> service supervision and system startup scheme?

I really like the way runit works. I'm a long time user of DJBware and 
know the concept of daemontools quite well.
Maybe I'd be happy with /package too.

But I'm a lazy boy, using a widely accepted Linux distribution saves me 
a lot of time. Therefore I want a drop-in replacement for SysV init.
Most people are like me. And that's the reason why most people stick 
with archaic software like SysV init. Give them an alternative that 
simply works in their current environment and is better / cleaner / 
smaller, and more developers / package maintainers would start putting 
daemontools-like run scripts into their packages, saving you the work 
of adjusting your setup on every host over and over again.

-- 
Bernhard Graf

Re: using runit as init

[Bernhard Graf]

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

-- 
Bernhard Graf

Re: using runit as init

[Bernhard Graf]

Charlie Brady wrote:

> On Wed, 9 Jan 2008, Mike Buland wrote:
> > 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.
>
> For instance, compile:
>
> main()
> {
>     pause();
> }
>
> into /usr/local/bin/pause, and then have a run script:
>
> #! /bin/sh
> do_something_you_care_about
> exec /usr/local/bin/pause

Nice. Will try it.
-- 
Bernhard Graf

Re: using runit as init

[Mike Buland]

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 ;)

RE: using runit as init

[rehan khan]

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] 
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

-- 
Bernhard Graf

RE: using runit as init

[rehan khan]

Although the dummy process resolves this particular problem it's not
very clean. I would prefer not to have processes knocking about which do
nothing.

Putting an 'sv d .' in the finish script seems to be the best solution
to run once scripts run by runsvdir. I still think that a mechanism
built into the runsvdir to handle run once scripts would be better.

R

RE: using runit as init

[Charlie Brady]

On Thu, 10 Jan 2008, rehan khan wrote:

>
> Although the dummy process resolves this particular problem it's not
> very clean.

"this particular problem"? You haven't quoted anything, so we don't know 
which particular problem is.

> I would prefer not to have processes knocking about which do
> nothing.

I'm guessing you are referring to my suggestion of a program which calls 
paus().

> Putting an 'sv d .' in the finish script seems to be the best solution
> to run once scripts run by runsvdir.

Yes, that sounds reasonable. That wouldn't be usable with daemontools, 
however. It also means that 'sv t .' would be a no-op, so wouldn't be 
usable with an init script wrapper which translated "service thing 
restart" to 'sv t /service/thing".

> I still think that a mechanism built into the runsvdir to handle run 
> once scripts would be better.

Perhaps.

Re: using runit as init

[Bernhard Graf]

Mike Buland wrote:

It seems you simply refuse the actual point of the discussion I started:

My goal is not to make runit like SysV init.

My goal is to replace init by something that supervises daemon processes 
in the sense of daemontools.

The discourse is about the way to that goal.

And of course about shortcomings in runit / other init system / the 
daemontools concept as process 1 in general. This should be allowed 
without making someone feel defensive.
-- 
Bernhard Graf

Re: using runit as init

[Mike Buland]

yes, you're completely right.  I'm sorry.  I do overstate and come off as a 
jerk sometimes, most times, maybe...

I feel that your proposal is effectively hacking a good system for supervising 
some/most/all processes and losing all the cool extras that runit offers.  
Really, if what you want is supervising daemon processes, runit does it well, 
but the rc scripts are not compatible with that concept.  They all start 
programs that daemonize themselves, or *shudder* fork bash and use bash to 
daemonize them.

I really like runit, but I believe that there is no good option for allowing 
runit to supervise these daemons without writing runit specific (ok, 
daemontools could run most of them) scripts.  That, or maybe using the 
program group hack from daemontools (I beleive chpst can do the same thing, 
it's burried in the docs though).

The problem is the forking/daemonizing, it means that when those processes do 
that, you're no longer supervising them.  I'm willing to try and help with a 
good way of doing that, but I fear there is none, sometimes these systems 
just aren't compatible with one another.

Fortunately, I don't have one run script that's more than 4 or 5 lines, and 
most of that is whitespace :)

Sorry
--Mike

On Friday 11 January 2008 12:58:32 am Bernhard Graf wrote:
> Mike Buland wrote:
>
> It seems you simply refuse the actual point of the discussion I started:
>
> My goal is not to make runit like SysV init.
>
> My goal is to replace init by something that supervises daemon processes
> in the sense of daemontools.
>
> The discourse is about the way to that goal.
>
> And of course about shortcomings in runit / other init system / the
> daemontools concept as process 1 in general. This should be allowed
> without making someone feel defensive.

Re: using runit as init

[Bernhard Graf]

Mike Buland wrote:

> yes, you're completely right.  I'm sorry.  I do overstate and come
> off as a jerk sometimes, most times, maybe...

I think you are overstating ... ;-)

But nevermind. The whole thread gave me some valuable input.

> Fortunately, I don't have one run script that's more than 4 or 5
> lines, and most of that is whitespace :)

Lucky you.
You don't run mysql, do you?
-- 
Bernhard Graf

supervising (Re: using runit as init)

[Charlie Brady]

On Sat, 12 Jan 2008, Bernhard Graf wrote:

> You don't run mysql, do you?

What's so hard about mysql (other than the parent process not passing on 
signals to children)?

-bash-3.00$ cat run
#! /bin/sh

exec 2>&1

exec /usr/libexec/mysqld \
  --defaults-file=/etc/my.cnf \
   --basedir=/usr \
    --datadir=/var/lib/mysql \
     --user=mysql \
      --pid-file=/var/run/mysqld/mysqld.pid
-bash-3.00$
-bash-3.00$ for i in control/* ; do sudo echo $i: ; sudo cat $i  ; done
control/d:
#! /bin/sh

exec kill -TERM $(cat /var/run/mysqld/mysqld.pid)
control/i:
#! /bin/sh

exec kill -INT $(cat /var/run/mysqld/mysqld.pid)
control/q:
#! /bin/sh

exec kill -QUIT $(cat /var/run/mysqld/mysqld.pid)
control/t:
#! /bin/sh

exec kill -TERM $(cat /var/run/mysqld/mysqld.pid)

supervising mysql (Re: supervising (Re: using runit as init))

[Charlie Brady]

[Sorry - missed a word in the Subject.]

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

* Bernhard Graf <list-supervision@augensalat.de> [2008-01-12 11:18:51 +0100]:

>> Fortunately, I don't have one run script that's more than 4 or 5
>> lines, and most of that is whitespace :)
>
>Lucky you.
>You don't run mysql, do you?

I do, but it could be done in less than 5 lines.  My current runscript
for mysql is 29 lines, but a lot of that is error checking and settting
variables, none of which would be required for a single person who knows
what he's doing.

mysqld is no more complex than anything else.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

RE: using runit as init

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

Vincent Danen <vdanen <at> annvix.org> writes:

> 
> * Bernhard Graf <list-supervision <at> augensalat.de> [2008-01-12 11:18:51 +0100]:
> 
> >> Fortunately, I don't have one run script that's more than 4 or 5
> >> lines, and most of that is whitespace :)
> >
> >Lucky you.
> >You don't run mysql, do you?
> 
> I do, but it could be done in less than 5 lines.  My current runscript
> for mysql is 29 lines, but a lot of that is error checking and settting
> variables, none of which would be required for a single person who knows
> what he's doing.
> 
> mysqld is no more complex than anything else.
> 

I think this is one of the problems with why runit has had slower takeup and initng and upstart are stealing it's thunder, in the major distro arena - no offence to the fine annvix distro. Much of the documentation available on the net provide these highly abreviated init scripts which might only apply to linux (runit is multi OS). This is not actually what is required in a general purpose OS. The scripts need to be complete in the sense that they can cope with most things thrown at them including incomplete configurations, initial startups etc. In fact when one gets to mad java apps like Tomcat and Hsqldb the scripts become nightmares as they have to cope with so many OS's and java versions and such like.

mysqld is an interesting example. On a freshly installed OS nothing is initialised for mysql. How would one cope with this situation? The fedora scripts ask the user for input and setup initial databases.

Runit does not have any in-built mechanism for this this scenario and it needs to be built into the supporting scripts. Runit also does not have any mechanism to signal the system that user input is required and that all other services should not write to the console while this is happening. Runit also does not have a mechanism to signal that a particular services needs to have exclusive access to the system (useful if one wants to migrate the rc.sysinit script to a bunch of runit services). The scripts built around runit need to take care of these situations. At the end of startup there needs to be some kind of indication that services have failed/succeeded for some reason otherwise they may go un-noticed.

In some ways I think runsvdir could use some additional functionality and I am thinking of re-implementing it in python. Runsvdir does in effect supervise all the runsv processes (when it is used) and would be a good place to co-ordinate this kind of activity (process signalling, holding a dependancy database). I probably need to do this anyway to get Linux Standards Base compliance.

It would be nice to see a collection of multi-OS (linux, bsd etc) init scripts somewhere out there. Perhaps if someone could help me out with the cvs/svn setup on the fedorafastboot project we can get a general script repository setup?

R

http://sourceforge.net/projects/fedorafastboot


[-- Attachment #2: Type: text/html, Size: 3606 bytes --]

Re: using runit as init

[Charlie Brady]

On Sat, 12 Jan 2008, Vincent Danen wrote:

> mysqld is no more complex than anything else.

Have they fixed it then, so that the master process kills children before 
dying?

Re: using runit as init

[Mike Buland]

Yes, read the (very lame) docs on mysqlmanager.  It also now responds to other 
signals (such as term) so it plays nicely with runit :)

mysqlmanager was introduced sometime in mysql 5, not sure when.

--Mike

P.S.  My mysql script doesn't do all of that, I leave it to mysqlmanager, and 
I don't worry about the database being there, the installer takes care of all 
that on my system.  I could probably do more with error checking, but I'm not 
sure what I would cover.  My script is two lines including the bash ID at the 
top.

On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote:
> On Sat, 12 Jan 2008, Vincent Danen wrote:
> > mysqld is no more complex than anything else.
>
> Have they fixed it then, so that the master process kills children before
> dying?

Re: using runit as init

[Charlie Brady]

On Sun, 13 Jan 2008, Mike Buland wrote:

> On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote:
>> On Sat, 12 Jan 2008, Vincent Danen wrote:
>>> mysqld is no more complex than anything else.
>>
>> Have they fixed it then, so that the master process kills children before
>> dying?
> Yes, read the (very lame) docs on mysqlmanager.  It also now responds to other
> signals (such as term) so it plays nicely with runit :)

This might actually mean "no". They haven't fixed the signal 
handling in mysqld, but have instead introduced a new complicated program 
to try to work around the issues.

> mysqlmanager was introduced sometime in mysql 5, not sure when.

Introduced in 5.0.3. Not used by default since 5.0.4.

Re: using runit as init

[Mike Buland]

Hey, a complicated program they made is better than one I have to manage.

If you do read the docs, they don't handle signals in mysqld, like I say, 
mysqlmanager does.  They don't defend it, but they do explain that the only 
way to safely shutdown mysql is to send it a command via the named socket.  
Since this can't be done easily from the commandline without a password, 
unless you configrue mysql to accept the command from root without a 
password, then this seems like a pretty decent solution, since this program 
basically supervises it's child mysql processes and sends them a safe 
shutdown signal when the mysqlmanager program receives a term signal.

All the scripts I've read from debian and redhat just send a kill...although 
this seems alright most of the time (and they are official scripts), that 
doesn't gurantee that data is flushed to disk, if mysql is in the middle of a 
large operation, that data is gone.  This solution does solve that problem, 
and keep runit from waiting for mysql to TERM.

--Mike

On Sunday 13 January 2008 11:39:56 am Charlie Brady wrote:
> On Sun, 13 Jan 2008, Mike Buland wrote:
> > On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote:
> >> On Sat, 12 Jan 2008, Vincent Danen wrote:
> >>> mysqld is no more complex than anything else.
> >>
> >> Have they fixed it then, so that the master process kills children
> >> before dying?
> >
> > Yes, read the (very lame) docs on mysqlmanager.  It also now responds to
> > other signals (such as term) so it plays nicely with runit :)
>
> This might actually mean "no". They haven't fixed the signal
> handling in mysqld, but have instead introduced a new complicated program
> to try to work around the issues.
>
> > mysqlmanager was introduced sometime in mysql 5, not sure when.
>
> Introduced in 5.0.3. Not used by default since 5.0.4.

Re: using runit as init

[Mike Buland]

If you don't mind, since I am actually interested, would you explain to me why 
you think I'm wrong.  Really about your solution for porting scripts not 
leveraging any of the advantages of runit.  If we can actually make runit 
better, I'm for it.  I'm just not yet convinced that any suggestions so far 
would help (insofar as increasing flexibility, adding features, and not 
overcomplicating).

--Mike

On Saturday 12 January 2008 03:18:51 am Bernhard Graf wrote:
> Mike Buland wrote:
> > yes, you're completely right.  I'm sorry.  I do overstate and come
> > off as a jerk sometimes, most times, maybe...
>
> I think you are overstating ... ;-)
>
> But nevermind. The whole thread gave me some valuable input.
>
> > Fortunately, I don't have one run script that's more than 4 or 5
> > lines, and most of that is whitespace :)
>
> Lucky you.
> You don't run mysql, do you?

RE: using runit as init

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

AFAICS the redhat scripts send a term, wait 10 secs then send a kill to the mysql processes ending with the parent process.

From what you guys are saying this is not the right way to stop mysql? If it isn't then someone should probably mention it to Redhat :)


Rehan


-----Original Message-----
From: Mike Buland [mailto:mike@geekgene.com]
Sent: 13 January 2008 19:01
To: supervision@list.skarnet.org
Subject: Re: using runit as init


Hey, a complicated program they made is better than one I have to manage.

If you do read the docs, they don't handle signals in mysqld, like I say, 
mysqlmanager does.  They don't defend it, but they do explain that the only 
way to safely shutdown mysql is to send it a command via the named socket.  
Since this can't be done easily from the commandline without a password, 
unless you configrue mysql to accept the command from root without a 
password, then this seems like a pretty decent solution, since this program 
basically supervises it's child mysql processes and sends them a safe 
shutdown signal when the mysqlmanager program receives a term signal.

All the scripts I've read from debian and redhat just send a kill...although 
this seems alright most of the time (and they are official scripts), that 
doesn't gurantee that data is flushed to disk, if mysql is in the middle of a 
large operation, that data is gone.  This solution does solve that problem, 
and keep runit from waiting for mysql to TERM.

--Mike

On Sunday 13 January 2008 11:39:56 am Charlie Brady wrote:
> On Sun, 13 Jan 2008, Mike Buland wrote:
> > On Sunday 13 January 2008 08:36:31 am Charlie Brady wrote:
> >> On Sat, 12 Jan 2008, Vincent Danen wrote:
> >>> mysqld is no more complex than anything else.
> >>
> >> Have they fixed it then, so that the master process kills children
> >> before dying?
> >
> > Yes, read the (very lame) docs on mysqlmanager.  It also now responds to
> > other signals (such as term) so it plays nicely with runit :)
>
> This might actually mean "no". They haven't fixed the signal
> handling in mysqld, but have instead introduced a new complicated program
> to try to work around the issues.
>
> > mysqlmanager was introduced sometime in mysql 5, not sure when.
>
> Introduced in 5.0.3. Not used by default since 5.0.4.





[-- Attachment #2: Type: text/html, Size: 3097 bytes --]

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 4155 bytes --]

* rehan khan <rehan.khan@dsl.pipex.com> [2008-01-13 10:35:40 -0000]:

>> >> Fortunately, I don't have one run script that's more than 4 or 5
>> >> lines, and most of that is whitespace :)
>> >
>> >Lucky you.
>> >You don't run mysql, do you?
>> 
>> I do, but it could be done in less than 5 lines.  My current runscript
>> for mysql is 29 lines, but a lot of that is error checking and settting
>> variables, none of which would be required for a single person who knows
>> what he's doing.
>> 
>> mysqld is no more complex than anything else.
>> 
>
>I think this is one of the problems with why runit has had slower takeup and initng and upstart are stealing it's thunder, in the major distro arena - no offence to the fine annvix distro. Much of the documentation available on the net provide these highly abreviated init scripts which might only apply to linux (runit is multi OS). This is not actually what is required in a general purpose OS. The scripts need to be complete in the sense that they can cope with most things thrown at them including incomplete configurations, initial startups etc. In fact when one gets to mad java apps like Tomcat and Hsqldb the scripts become nightmares as they have to cope with so many OS's and java versions and such like.
>
>mysqld is an interesting example. On a freshly installed OS nothing is initialised for mysql. How would one cope with this situation? The fedora scripts ask the user for input and setup initial databases.

Depends on the OS.  For annvix, the default database is setup when the
rpm is installed.  I believe most distros do something similar...
granted, I don't use much beyond annvix and mandriva, but I can't
imagine anyone thinking that an initscript is a good place to be asking
for user configuration.  Initscripts should be non-interactive... it
certainly isn't the right place to be asking users for configuration info.

>Runit does not have any in-built mechanism for this this scenario and it needs to be built into the supporting scripts. Runit also does not have any mechanism to signal the system that user input is required and that all other services should not write to the console while this is happening. Runit also does not have a mechanism to signal that a particular services needs to have exclusive access to the system (useful if one wants to migrate the rc.sysinit script to a bunch of runit services). The scripts built around runit need to take care of these situations. At the end of startup there needs to be some kind of indication that services have failed/succeeded for some reason otherwise they may go un-noticed.

This could be useful, granted, but doesn't necessarily need to be done
by runit.  A simple script called after everything gets started could
check to see what is down and should be up, then report on those.  with
annvix, we use a frontend to sv called srv, and srv --list will tell you
what is up, down, should be up, when it changed state, etc.

But I don't think runit needs to change to allow people to execute
configuration during service startup becuase I think these services
should be configured before they're told to start.

Distros that use initscripts to setup services themselves are, imho,
bastardizing what initscripts were designed for in a very wrong way.

>In some ways I think runsvdir could use some additional functionality and I am thinking of re-implementing it in python. Runsvdir does in effect supervise all the runsv processes (when it is used) and would be a good place to co-ordinate this kind of activity (process signalling, holding a dependancy database). I probably need to do this anyway to get Linux Standards Base compliance.
>
>It would be nice to see a collection of multi-OS (linux, bsd etc) init scripts somewhere out there. Perhaps if someone could help me out with the cvs/svn setup on the fedorafastboot project we can get a general script repository setup?

The annvix svn is open and we have runscripts for a number of services
that can easily be cherrypicked by anyone interested.
http://svn.annvix.org/.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

* Charlie Brady <charlieb-supervision@budge.apana.org.au> [2008-01-13 10:36:31 -0500]:

>> mysqld is no more complex than anything else.
>
> Have they fixed it then, so that the master process kills children before 
> dying?

No, but my mysqld.finish script calls "mysqladmin shutdown" and has for
a few years now with no adverse effects at all.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

* Mike Buland <mike@geekgene.com> [2008-01-13 11:49:58 -0700]:

>Hey, a complicated program they made is better than one I have to manage.
>
>If you do read the docs, they don't handle signals in mysqld, like I say, 
>mysqlmanager does.  They don't defend it, but they do explain that the only 
>way to safely shutdown mysql is to send it a command via the named socket.  
>Since this can't be done easily from the commandline without a password, 
>unless you configrue mysql to accept the command from root without a 
>password, then this seems like a pretty decent solution, since this program 
>basically supervises it's child mysql processes and sends them a safe 
>shutdown signal when the mysqlmanager program receives a term signal.
>
>All the scripts I've read from debian and redhat just send a kill...although 
>this seems alright most of the time (and they are official scripts), that 
>doesn't gurantee that data is flushed to disk, if mysql is in the middle of a 
>large operation, that data is gone.  This solution does solve that problem, 
>and keep runit from waiting for mysql to TERM.

Hmmm... I didn't know anything about this mysqlmanager.  Care to share
your runit script?  =)  I may have to look into using that instead of
calling mysqld directly.

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: using runit as init

[Charlie Brady]

On Sun, 13 Jan 2008, Vincent Danen wrote:

> Hmmm... I didn't know anything about this mysqlmanager.  Care to share
> your runit script?  =)  I may have to look into using that instead of
> calling mysqld directly.

Why? You haven't had any trouble reports about mysql startup, have you?

Re: using runit as init

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

* Charlie Brady <charlieb-supervision@budge.apana.org.au> [2008-01-14 10:11:41 -0500]:

> On Sun, 13 Jan 2008, Vincent Danen wrote:
>
>> Hmmm... I didn't know anything about this mysqlmanager.  Care to share
>> your runit script?  =)  I may have to look into using that instead of
>> calling mysqld directly.
>
> Why? You haven't had any trouble reports about mysql startup, have you?

No, actually mysql runs quite reliably the way I call it, and with using
the mysqladmin shutdown command to turn it off.  But if there's a better
(more proper) way to do it, then I'm interested in looking at it.

mysqlmanager does look interesting.. looks like you can manager more
than one database instance starting from the same supervisor instance,
so I could be running a local-only db, a remote db, and another remote
db, just by fiddling with /etc/my.cnf and restarting the manager.

Just because it's worked for me doesn't mean it's not possible for it to
bork something... maybe I've been lucky, maybe mysql is robust enough to
handle it... maybe what I'm doing is perfectly acceptable, but there's
nothing wrong with looking at the "recommended" way of doing things.  =)

-- 
Vincent Danen @ http://linsec.ca/

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]