Re: Debian boot system
Hi!
On Sat, 7 Oct 2000, Eyal Lotem wrote:
> No. You need to create a Makefile, that can be SEPERATELY and INDEPENDENTLY
> managed (forget rc*.d). No merging, not much of anything, just an
> auto-generated/maintained makefile, in an easily modifiable format.
>
you will have to create an API with the functionality to add, modify and
delete services including defining dependencies.
> Basically, all that needs to be specified, are the dependencies. As I
> already have specified roughly, in my Makefile draft (that works fine, btw),
> and took about 5 minutes to make.
> All the actual work to parallize, is done by make.
>
Yeah, make will do the parallisation, but did you ever think about the
output of the starting services? As stated in make's info there is NO
guarantie that the output might get not mixed. How will you cope with that
by simply using make? Did you ever think about that? You would have to
seperate the output of the services and then to put it together again. But
that would create a problem when debugging unknown dependencies. I mean
when a failure happens in parallisation and two services are started
concurrently and it happens that some struggling code pieces are executed
together. Reproducing such events would be hardly possible due to
race-conditions. Debugging for the error without knowing when and what was
running is also impossible.
> True, the Debian packages of daemons and other boot-related software need a
> change to support maintaining the boot Makefile.
>
An API as stated above would do that (some shell commands perhaps?)
> I do not know much about the problems the LSB guys are encountering, but if
> they are, their problem is probably not very similar to this one, because in
> this one, its quite trivial to specify the obvious dependencies (at least all
> that are handled by the sequential boot system).
>
> I think its worth the trouble, especially when you consider a complete
> Makefile, containing ALL the dependencies from the rc*.d scripts took minutes
> to make and should be quite easy to be software-maintainable.
>
mmh, I don't want to think about the mixed output.
> I think the more graceful error recovery (remmember the
> hostname-not-resolvable sendmail problem?), and the extra flexibility (the
> ability to easily specify the SPECIFIC dependencies (Current systems, for
> example, will sometimes not shutdown correctly, and try to unmount NFS after
> shutting down the network, because the order is specified manually, instead
> of being deduced from simpler[to humans] dependency specifications)
>
if your thing is sometime doing the output right, it really would help in
such cases.
I hope that you will make it.
--
kind regards,
Michael Moerz
Reply to: