Defining the workgroup objectives

[Gerrit Pape]

On Mon, Aug 01, 2005 at 06:00:20PM +0200, Sven Mueller wrote:
> Gerrit Pape wrote on 31/07/2005 21:20:
> > A good dependency concept not only finds out the right order to startup
> > services, but also to shut them down.  A real good dependency system
> > takes service dependencies also into account when a single service is
> > taken down (think removing packages) or terminates unintentionally while
> > system uptime.
> 
> Sorry, but your runit concept doesn't seem to handle dependencies at
> all, at least not during startup. It might make sure all dependency
  
Hmm, I'm pretty sure it does, and already explained it in this thread.
Maybe it doesn't do it the way you think it should be done, or you
didn't grasp it yet.  How about you name two or three services in Debian
you currently use, and which need dependency handling, and I show you a
runit configuration for them that works, on startup as well as while
system uptime?
  
> runscripts are (trying to) start, but it doesn't handle the dependency
> in an intelligent way (i.e. only starting X when it's dependency on is
> actually fulfilled, not only trying to be fulfilled).

Starting the run script isn't starting the service.  It's not the run
scripts that needs dependencies, but it's the services, if at all;
runit handles it just fine.  From my experience very few services
actually need dependencies, and that actually only because they haven't
been designed properly to deal with failures.

> > Regarding your question above, this would be handled automatically by
> > runit, as it will restart the "hold" service if it fails, until it
> > succeeds eventually.  If you don't think that's a "clean" solution, or
> > the startup of this specific service takes a lot of resources, add a
> > check for the dependency to the top of the run script (before execing
> > into the daemon), and either wait, or simply exit to be restarted.
> 
> Sorry, but this is exactly what I expect from a dependency based init
> system: Only start a service, when the dependencies _are_ fulfilled.
> And

Sure, and that's what happens.  Normally the services are configured so
that dependencies are fulfilled, there's also dpkg.  If there's a
dependency problem, there's a misconfiguration, and the init scheme
should deal with that.  Additionally it can help the admin when managing
services of course.

> to only stop a service which is depended upon when all those services
> which depend on it are already stopped.

Really?, how about restart, implemented through start/stop?  If you
restart a service, need the dependent services to be restarted too?
Almost never I think, but if so, you can tell runit to do so.

> I expect that a service lets the init system know when it is started
> succesfully.

That'd be nice really.  But if you start to fix all the service daemons
existing in the Unix worls to comply with such an inter process
communication, you most probably never finish, IMHO.

> > System startup is just a minor part of init's duties in my opinion.
> 
> You mix a daemon babysitter process with the init system in my opinion.
> A babysitter process has to start or stop the daemon when asked to do so
> (and doesn't need to know about dependencies), the init system has to
> handle dependencies and start/stop daemons or ask the babysitter process
> to start/stop them. In my opinion, it makes no sense to mix these two
> things together, especially when you forget to handle dependencies along
> the way. Simply starting all services in parallel and restarting those
> that terminate uses a lot of resources on larger machines, effectively
> slowing down the boot (yes, I did try that two years ago, though not
> with runit) under various circumstances instead of speeding it up.

You should really try it out, don't speculate.  It's not vapor-ware,
it's implemented and works.  BTW, it wasn't a goal to speed up system
boot when runit was designed, it was a positive side-effect, and people
jumped on this.

> BTW: I ran across daemons before which didn't even have a --no-fork (or
> equivalent) option. Can't currently remember which though.

Yes, so was I.  Fortunately all those I've found or used are fixed in
the meantime, except for apmd.

> Also, your run scripts miss an important part in the init system, which
> is easily possible with sysv-Initscripts but impossible with your run
> scripts as far as I can tell:
> Some daemons _need_ some cleanup actions to be performed after the
> daemon exits. In some cases the local admin might want to do something
> when a daemon is shut down (e.g. create a dump of some important
> database when the database server is stopped, or notify a remote system
> of the shutdown).

See the runsv(8) man page, search for 'finish' script, it's there.

> Also, I have seen daemons which simply disable parts of their
> functionality if some other dameon those parts depend on isn't available
> at startup. How do you handle that with runit?

(1) In the run script test for the availability of the dependencies
before starting the service daemon, I alread wrote that in this thread;
(2) think about whether this is good design of the software doing that,
and if you come to the same conclusion I do, discourage that behavior
when talking to software authors.  Still, runit can deal with this.

> Also, sysvinit allows to reload/force-reload some daemon, how do you
> handle that with runit? I can't see how you do that.

Take a look an the sv(8) man page, it implements an LSB init scripts
interface, and lets you send signals to the service daemon, reliably,
without the need of pid files.

> What I really expect of any init system are various things:
> 1) Make sure no service is started when its dependencies are not met
> 2) Allow a graceful shutdown, taking services down before their
>    dependencies are stopped
> 3) Allow manual stopping and starting of services, handling dependencies
>    and giving feedback what services were actually started/stopped or
>    failed to start/stop
> 4) Allow some equivalent to the /etc/init.d/<service> (force-)?reload
>    functionality
> On a truely dependency based init system, I would also expect the system
> to allow the local admin to:
> a) ask the system which services some service depends on
> b) ask the system which services depend on some service
> c) manipulate the dependencies of a service

I don't see anything in your personal wishlist that runit can't do.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.