Defining the workgroup objectives

[Sven Mueller]

Gerrit Pape wrote on 03/08/2005 20:41:
> On Mon, Aug 01, 2005 at 06:00:20PM +0200, Sven Mueller wrote:
>
>>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?

Ok, real-world example:
drbd (network shared) partition must be mount for
mysql daemon to be able to start.
mysql must be up and running for postfix to start
spampd depends on mysql as well and is needed by postfix
postgrey depends on mysql and is needed by postfix
Note that the way postfix is configured, it disables greylisting if
postgrey isn't up, but starts and works as intended otherwise (accepts
mail....)

So this is:
drbd
	depends on networking
mysql
	depends on drbd
postgrey
	depends on mysql
spampd
	depends on mysql
postfix
	depends on mysql
	depends on spampd
	depends on postgrey

As I understand it, I would need to check in the postfix-runscript that
postgrey is actually up and running. However the only way for me to test
that in a shell script is to check wether its PID-file exists and
relates to an existing instance of postgrey as far as I can tell.
It is no problem with classic init scripts because when the postgrey
init script returns 0, postgrey started cleanly and detached itself when
it was ready to service postfix's requests.

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

Oh well. It surely depends on how you define "properly deal with
failures". In some way, I agree with you: services should be able to
wait for the services they depend on to be available before they
themselves offer their services. However, reality is different to this,
and in some cases, I can even see why it's like that.

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

I don't understand you properly I assume.
Once you said that runit simply starts all services in parallel, now you
 say runit handles the dependencies properly. And what do you mean by
"Normally services are configured so that dependencies are fulfilled,..."?
As I understand it, when service A depends on B, runit only makes sure
that a runscript for B exists (and is/can be executed) before starting
A. It doesn't make sure though that B actually starts (the service, not
the runscript), or did I misunderstand the documentation and/or your mails?

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

That would be rare, but for some _really_ badly designed services, it
might actually be needed.

> Almost never I think, but if so, you can tell runit to do so.

Fine.

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

Probably. But actually, most daemons already have one way or the other
to get their current state from a script (most, not all). So it would be
possible for the start script to wait until the service is running and
then let the init system know about that. Not possible for all services,
true, but possible for almost all services upon which other services
might depend.

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

As I said: I did try the effect of an init system which simply started
all services in parallel and restarted those that failed over and over
again (until they were all running). And on two of the larger servers,
this actually slowed down the boot process (by some 20%). That wasn't
runit, but it did what I described above and that is what I understood
runit does. If runit works differently, your mails were either
over-simplifying the way runit works or I misunderstood you. BTW: As I
said above: It slows down the boot on some large machines. On most
desktops, it speeded up the boot process by 20-50%.

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

Interesting. What was the design goal then?

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

Nice. Too bad apmd doesn't allow that yet.

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

Ok, in that case I overlooked something.

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

Oh well, I only wished there was a standard way of telling wether
service X is currently available. In theory, "/etc/init.d/X status"
should do that, but then again, that is a sysv-init-based system (and it
doesn't always work).

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

Like in the case of postgrey and postfix, it might not be optimal to
simply disable greylisting, but for some people it is more important to
be able to receive mail at all than to receive as few spam mails as
possible.
So: In some cases, this is wanted behaviour though it should be avoided
to do such a failure.

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

Cool, once again something I overlooked. Seems I got carried away by the
(simple) way you described runit in your mails.

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

Ok then. Please show me for the dependencies I listed above how I
achieve 1 and 2 (it's Ok to shortcut on checks in the scripts, simply
write check_for_X or something in place of an actual check), if not too
difficult, 3 would also be nice. I checked the docs again (though not
thoroughly), but I still don't see how you actually work with the
dependencies. Maybe it's simply too late at night already but anyway...
Also it would be nice to give an example of how to add/remove a
dependency or ask the system what dependencies need to be fulfilled for
some service to start.

Not only for me, but also for the other readers. I think seeing actual
examples of the runit system helps to understand it far better than
everyone reading the docs.

cu,
sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20050805/1f2806c5/signature.pgp