[Initscripts-ng-devel] Defining the workgroup objectives

[paddy]

On Tue, Jul 26, 2005 at 08:55:52PM +0200, Sven Mueller wrote:
> paddy wrote on 26/07/2005 19:29:

> I also wonder what should happen when the local admin
> calls an init script directly which doesn't have its dependencies met.

In the sense that it depends on a service that happens to be stopped ?
or in the sense that it depends on something that simply isn't there ?
or in the sense that conflicts with somehting that is already running ?

In general I'd say the behaviour should default to whatever would happen
in the boot sequence.  Override options might be useful.

In the first case, I'd say it should meet the dependencies.
In the second case, I'd prefer it to fail.

In the third case, I'm not sure.  If this is like a switch to a runlevel
where the conflicted service is stopped, then do it.  If this is like 
asking for a switch to a runlevel that is inconsistent, then fail. 
If it can be detected before any changes are made, then perhaps it is 
best to fail at that point in time.
(or perhaps to have a default that varies per target, so that you can
say "always try to run rc.S")
And if there is no way to tell the difference between these two ?

I'm a bit nervous about starting a service automatically stopping another 
service.  In the sysvinit system only runlevels do this ?

> Note: I call everything done by init scripts a service, where a
> "running" service could simply be some configuration being activated
> (like some iptables entries being made on start and removed on stop) or
> an actual running server. Init-Scripts (or service-scripts) should
> report consistently (upon request) wether a service is currently
> "stopped", "starting", "running" or "stopping", where starting could be
> used to avoid running the service script a second time while it is still
> running from a previous call, bringing the service up, stopping would be
> used accordingly for the "stop" action. However, given that this would
> mean a change to every single Debian package which provides an init
> script, I would say that "starting" and "stopping" are optional if the
> script handles double calls gracefully.

Yes, even mandating status is a big step.  It would be good to get other
relevant bits on the rider at the same time :)

Polling seems more important than traps, but I wonder whether there is
a place for things like respawn, or a more general 

	when 'x has stopped' do y and z

> From a simple administrators POV, I would expect a dependency driven
> init system to
> 1) co-exist with old-style init scripts

At first blush this is a must have, but I worry about how to get it.

Can a new (dependency) service depend on an old (ordered) service ?
Can an old service depend on a new service ?
see also below.

> 2) handle dependencies gracefully when the local admin manually starts
>    or stops a service (this could mean automatically starting the
>    dependencies respectively stopping the reverse dependencies OR simply
>    reporting _why_ the service currently can't be stopped or started).

agree.  

The alternative to allowing failure is 'everything is a valid program'.
Oh! how I miss the spectacular crashes on the Apple II

dependency cycles come to mind as well.

> 3) Allow several, distinct runlevels for easy switching
> 4) Allow easy addition of a service to some runlevel
> 5) automatically check for contradictions (like explicitly stopping
>    networking and starting sshd in some runlevel, with sshd depending
>    on networking, obviously).

At configuration time or run-time ?
configuration time might be good.

> 6) Allow three states of a service per runlevel:
>    has to run, has to be stopped, don't care

Is this equivalent to
	has an S link
	has a K link
	has neither S nor K link
?

This allows zany things like what is running depends on which runlevels
you've travelled through :) 

does this conflict with existing debian policy ?

But in a dependency system you can get the same effect by having a service
that depends/stops on everything it cares about.

perhaps in a dependency system a runlevel becomes just a kind of service?
or perhaps the ability to stop things puts an object in a different class?
hmmm, first-class and second-class services.  not sure I like that.

> 7) A service should be able to declare several relations to other
>    services:
>    Provides, Conflicts, Depends, Before

I miss Intercal's COME FROM in other languages ;)

I take it Before is the reverse depends that enables old services to
depend on new services (see above).  In that case, every old service
needs to call into the dependency system to get its dependcies
fullfilled?  Perhaps /sbin/service service start needs to replace
/etc/init.d/service start ?  Does direct execution of /etc/init.d/service
need to be prevented or made more dificult under such a system ?
or does it get you non-dependency semantics ?  
Is there any rule says one init.d script can't call another one directly ?

> Regarding 7: I could see some occasions where a service wants to be
> started _and_ stopped before some other service is started or stopped,
> while the normal situation would be if X requests to be started before Y
>  that it would be stopped after Y is stopped.

Cool! example ?

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall