[Initscripts-ng-devel] Defining the workgroup objectives

[Sven Mueller]

paddy wrote on 26/07/2005 19:29:
> heartbeat contains an init system,

Well, yes, in a way it does.

> I'm not aware of special mechanisms in heartbeat1 for making a service
> depend on a service on another machine, as the original poster asked,
> but another post here describes how that can be trivially done.
> I don't know whether such is slated for heartbeat2.

Neither do I, but you are right in a way: with a truely dependency
driven init system, it would really be possible to simply depend on some
local "service", which reports that it is running only when it detects a
remote service as running.

> I hope heartbeat will be considered in the initscripts-ng-devel
> discussion.  This seemed like a plausible excuse to bring it up.
>
> For example, I understand heartbeat uses init scripts which are lsb
> compliant - its expects strict interfaces, behaviour and output.
> The current debian init-scripts cannot be used directly,
> but need wrapping (not that I find this especially onerous).

You mean error messages from heartbeat like these? (abbreviated)
hb: info: Running /etc/init.d/postgrey  stop
hb: ERROR: Return code 1 from /etc/init.d/postgrey
hb: ERROR: Resource script for postgrey probably not LSB-compliant.
hb: WARN: it (postgrey) MUST succeed on a stop when already stopped
hb: WARN: Machine reboot narrowly avoided!

Yes, I'm totally on your side. IMHO, Debian policy should mandate that
all init scripts be LSB compliant, especially in the sense of reporting
success when they are asked to stop a service which already runs.

> As another example, consider a dependency driven init system.
> Should it only address services in its own namespace ?
> And have heartbeat is a seperate namespace ?

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

> Cross-machine dependencies seem like a natural enough aspect of
> some clusters, and more and more clustering software is being
> developed and going into Debian.

True, but it is hard to model an init system for these without intimate
knowledge of the local setup (e.g. the hostname of a database server). I
would say that we should model the system in a way which allows
resolving of local dependencies only but allows easy local addition
(perhaps in the form of an overrides file) of more dependencies. And
then document how to use this to create a local pseudo-service which
actually only checks (or waits for) a remote service.

> It may be that whole problem is simply too big to consider in the
> context initscripts-ng-devel, but I would be wary of simply
> ignoring it.  By considering the wider picture, we might learn
> something, or avoid mistakes.

True.

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.

>From a simple administrators POV, I would expect a dependency driven
init system to
1) co-exist with old-style init scripts
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).
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).
6) Allow three states of a service per runlevel:
   has to run, has to be stopped, don't care
7) A service should be able to declare several relations to other
   services:
   Provides, Conflicts, Depends, Before

4+5 could (or even should) be handled by some commandline tool (possibly
with curses interface or even an X capable frontend).
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.

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/20050726/c1788445/signature.pgp