Re: makefile-init
> I hope this isn't too off-topic.
Doesn't usually stop anyone.
> There has been some talk about a makefile-style replacement for the
> sysv init mechanism. Has this been worked out in any detail?
Not to my knowledge. Certainly no specific planning to design or implement
anything of the kind has been done by the Hurd developers.
> I suppose the basic idea is to generalise run levels with
> dependencies: before a service is started, all the services that it
> depends on are started, and before a service is stopped, all the
> services that depend on it are stopped. But:
That's the idea that makes sense to me. Everything further you ask about
verges on more detailed than I think anyone has clearly worked through.
If you wanted to work it through and implement it, that would be a fine thing.
> How are dependencies from different packages combined?
What do you mean exactly? I don't see anything complicated about combining
files installed by many packages.
> Are service dependencies linked in any way to package dependencies?
I can only guess precisely what it is you are talking about.
For a given service, there are two kinds of relationship it can have with
other services. There is "B will only work if A is already working", and
there is "if you have both A and B then you want to start A first". The
former kind of relationship translates to a package dependency, and the
package makers might want to have package dependencies produced
automagically from the init dependency configurations included in packages.
But there is no special way that these dependencies "are linked" to the
package dependencies any differently than e.g. shared object dependencies.
> Do you provide a respawn facility, or should every daemon that
> provides an essential service and thinks it might crash take care of
> this itself (by forking and letting the parent respawn the child)?
There are enough extant things that need to be restarted when they die that
we need to make it easy to deal with such things. It's always possible to
do this just by providing a watcher program that one uses explicitly to
start each such service, but it it might or might not be the best thing to
have that facility built in to init.
> If you don't provide a respawn facility, do you still need a process
> ("init") that runs forever?
No, I don't see why you would. (Note that in the Hurd, we have /hurd/init,
which runs forever and will continue to do so. But /sbin/init is what
would be replaced by a new facility we are discussing.)
> If you do provide a respawn facility, do you think the system could
> also take care of remembering pids so that each daemon doesn't have to
> implement its own slightly buggy variant of creating and reading
> /var/run/*d.pid, with or without file locking depending on whether the
> programmer can be arsed or not?
>
> A case that can be rather awkward at present is when you want to run
> several instances of a daemon. Usually it's possible, but the way to
> do it is different for each program: for openssh, you create separate
> config files that specify different PidFiles; for fetchmail you have
> to run the program as non-root with a different value of $HOME, I
> think; ...
All of these issues are things that can be usefully addressed by a helper
program of some sort, whether that is a per-service watcher program or part
of init.
Reply to: