"minit" point of view

[Erich Schubert]

Hi,
I'm the maintainer of the minit package (which I, admittedly, have
neglected a bit)

I havn't yet caught up with all your discussions on the list, but
here's a short overview of my experiences with alternative init
methods (and also with hacking on them; I've been running a modified
minit on my laptop for more than two years now)

- init as of now does two tasks - supervise services and handle the startup
- pid 1 has a special role in linux, making it better suited for
respawning than other pids
- other pids can manage service startup and shutdown as well
- feedback to highlevel (e.g. dbus would be nice)
- communication with pid 1 is tricky (no networking yet, no rw-filesystem!)
- there is a difference between a service being launched and being available!
- dependencies can resolve themselves (if you prevent loops)
- a non-trivial integration obstacle is invoke-rc.d
- output handling (logging...) is also an issue...
- some processes (e.g. cron, at) don't have a no-daemonize mode

First some words about superivision:
Supervision is important, and is where sysvinit is really lacking.
While sysvinit does have supervising capabilities - e.g. for gettys -
it doesn't have startup sequences for them, so you can't really use
them for e.g. apache.
That supervision is important should be obvious by the existence of
dozens of such tools, e.g. monit, runit, daemontools, minit, svtools,
...
- trusting your applications to work fine is okay, but having them
respawn on failure is also important, especially for embedded systems
(!).

Now why is it best to have pid 1 do the supervision:
The cheapest way to monitor if a process is still runing is to be the
process' parent.
Then you can just wait for a signal when it dies (and maybe needs to
be restarted).
This is a well-known fact used e.g. by daemontools or by runit.
Unfortunately, if a daemon forks into the background, this trick will
not work. minit has a workaround for that: a helper that waits for the
fork, then waits for the pidfile, and tells the supervision process
the correct pid of the daemon.
Part of the reason for "daemonizing" is to detach from the parent
process - and this also happens here. So this hack works only if the
supervision process is pid 1 - because pid 1 will become the parent of
the "detached" process!

Furthermore, the runlevel management might also need to be restarted. ;-)

On dependency management:
If you have startup scripts that try to start a service they depend
on, eventually block while that service is starting, and fail if they
don't start, you don't have to care for dependency resolution at all!
Basically this is how topological sort works - start anywhere and wait
for everything that needs to be in front of you.
The only thing you need to pay attention to is loops - loops will
easily block, and instead should fail.
Another thing you might want to have is alternatives or "provides".
these are trickier to handle, I guess it's best to have a "virtual"
service for these that just tries to get one providing service up.

On services being available vs. being launched:
Consider a service which needs to know your IP address and interfaces.
It can't start until the interfaces are configured. So if you have a
service, lets say "networking", which brings up your interfaces, it
may often work to just "kick off" the networking service, then start
your daemon. On systems with a static IP, networking may be fast
enough to bring up the interfaces before the service queries them. But
now consider a case with DHCP, and maybe a non-working or a slow DHCP
server!
minit solves this by having a flag "sync" for a service. This enables
the following behaviours: 1. no other daemons will be started while
the "sync"ed service is starting 2. minit will wait until the script
is completed, then return
Maybe networking was a rather bad example, I use that to bring my
filesystems into rw mode... and 1 is more of a side effect of minit
running single-tasked.
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...

On output:
Certain bootup scripts (e.g. mounting filesystems) and some daemons,
especially in foreground mode expect to be the only process writing to
the console at a time.
This means, they don't write complete lines and then flush etc.
When you run two startup scripts at the same time, consisting of something like
---
echo -n "Starting service foo..."
foo&
echo " done."
---
You might end up with the output
---
Starting service foo...Starting service bar... done.
done.
---
Assume the laste line were "failed" - which one has failed?

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