Re: Problems with init
Radovan Garabik <garabik@melkor.dnp.fmph.uniba.sk> writes:
> there was a discussion on (I think) debian-devel not such long ago about
> replacing current debian init scheme with something more Makefile-based,
> with dependencies
> People generally liked the idea, but feared the work it'd take (I, for
> myself, would support it)
It took a bit of work, but it is all completed now. You could just
take it.
> Do NetBSD startup scripts providel reverse dependencies?
> I mean, when you are starting e.g. nfs-server, it depends on
> nfs-common, that depends on portmap, and that depends on networking,
> so these scripts are run in correct order.
> And when I decide to stop networking, does it know to stop first
> nfs-server, then nfs-common, them portmap and finally networking?
Yes. We have a mechanism to handle stopping services in the correct
order. You might want to read the paper Luke wrote on the whole thing,
or read our man pages.
> > init script behavior is pretty trivial in our system, except for the
> > fact that we don't have run levels. We decided that in practice people
> > don't actually need or use run levels although they very often claim
> > to want them.
>
> Of all the runlevels there are, I ever used only 2 (default), 6 (reboot),
> 0 (halt), 1 (single user).
> So there for the need for runleves :-)
Well, "halted" and "reboot" are not really states of the machine that
init needs to worry about. (It needs to worry about shutdown scripts
but we do that already.)
Our init already handles single user and "default", so in some sense
we already do what most people want so far as I can tell, at least in
practice.
I've never been anywhere where I've seen System V runlevels actually
used for changing the state of a running machine in practice between
one multi-user state and another. When we were re-designing NetBSD's
init/rc system, we solicited information on such use. Although legends
popped up of machines that changed the state of a database for an hour
once a week for various purposes, so far as we could tell cron jobs
that simply told the database to change state and such would have done
just as well. We therefore went with a "traditional" system without
System V style explicit runlevels.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
Reply to: