"minit" point of view

[Erich Schubert]

Hi,
> > - feedback to highlevel (e.g. dbus would be nice)
> *Pretty* please with sugar on top, make this an add-on. Let's *not*
> drag d-bus into the core. No no no.

I never suggested that it should be in the core.
In fact, what I like a lot about the minit thing is that the core is
really minimal.
minit core is less than 7k, statically linked.

When I wrote my runlevel manager for minit, I saw how easy it is to
separate off functionality from the core. Basically my runlevel
manager monitors a directory (or to be precise: a symlink to a
directory is more useful) via dnotify (i.e. very efficient) and
changes are executed via calls to the core init. This part is less
than 6k statically.

> I envision some sort of table that keeps track of processes, such
> that I can write in there that PID 1234 should be restarted if it
> dies. Now, whether PID 1234 is a startup script of the detached
> daemon, when init receives a SIGCHLD, it can consult the table to
> decide on the next action.

You can do that, but only if the pid 1234 is your child, or if it was
detached and you are init. AFAIK.

> FWIW: a topological sort is nothing more than a depth-first search
> down the dependency links, where the action of marking a node
> visited (black) is that of starting the corresponding daemon.
> I don't think the grey state needs to be considered even in
> parallelised mode.

We don't need to do any of this actual search. It will resolve itself.
Basically each service says "yeah, but please start my dependencies first".
And it'll work just fine (unless you have loops, that is)

> > The only thing you need to pay attention to is loops - loops will
> > easily block, and instead should fail.
> 
> These are trivially handled with the grey state.

No, they are not. You have "race conditions" in parallel resolving.
Assume the following dependencies:
a -> b
b -> c
d -> c
d -> a

The system tries to start a and d. a enters grey state, waiting for b.
d enters grey state, waiting for c. assume c goes up, while b takes
some time.
So d is unblocked by c, and now depends on a. But a is in grey, so it
assumes a loop!

If you want to be able to easily detect loops, you need to keep track
which service requested which other service to come up. Then you can
do a loop detection on that.
Note that this information is useful for rollbacks, too.

> Then again, are there really services we would use Provides for,
> maybe apart from the MTA?

outside network connection, if you have multiple.

>   - Why would I depend on just any web server? I will depend on the
>     web server which I have configured.

Virtual services include cases where the provider is not known.
Assuming you have a local web search engine installed, you'll want it
to depend on your local webserver. You don't want to have to edit this
dependency when you switch from apache to apache2 - the dependency
should be just "web-server".

>   - Why would I depend on a database server? MySQL and PostgreSQL
>     are not compatible.

Still your app might be able to use both. It might even be able to use
both at the same time, doing like, a data transfer or comparison.

> Why block other services in (1). It makes no sense to block service
> startup sequences in disjoint vertex sets in the topological graph,
> right?

This solves a lot of issues for stuff like mount-filesystems.
Most of the non-daemon cases are sync.

> > But I hope you got my point: you can depend on a background service
> > being launched, or you can depend on a background service actually
> > being available for requests...
> 
> Why would you ever depend on a background service being launched?
> For me, it's always been the "running"/"ready" state, and nothing else.

Speed reasons. I just want it to be started, but I don't immedeately need it.
Like postfix - you might want it to depend on your dns service, but
they can easily start at the same time.
Don't overdo dependencies, this will just slow down and increase the
workload (e.g. restarting your mail service just because you restarted
your dns service)

> There are trivial implementations for console output queues, though
> none without drawbacks. My preferred approach would actually to get
> rid of 'echo -n' and just do

Yeah, but you want them to be minimal, have static and limited memory
requirements (for embedded systems on nommu you really want your init
to never call malloc() again!) etc.
Then it gets really messy...

Having the "policy" of not outputting incomplete lines doesn't really
do the trick.
E.g. you'll want to eventually run fsck. It doesn't adhere to this policy.

best regards,
Erich Schubert
--
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
  To understand recursion you first need to understand recursion.   //\
  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
        eine Stunde wie eine Heimat aus. --- Herrmann Hesse