Subject: Re: On the proposal to augment NetBSD startup system
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 12/04/1999 20:30:28
[ On Saturday, December 4, 1999 at 15:16:57 (-0700), Lou Glassy wrote: ]
> Subject: Re: On the proposal to augment NetBSD startup system
> Yes, but I'm not advocating that rc+rc.conf be put under the existing
> package system. I think a new "SysV Init" setup could be packaged...
It depends on how totally you want to go with the SysV model.
Certainly packaging up a system where all the daemons are run from
inittab too would be a lot more work, especially for those daemons that
don't already have command-line flags to force them to say in the
foreground but not to spew too much debugging gunge.
I've considered doing this in the past but at the moment I'm already
maintaining a lot of little un-related tweaks and changes to NetBSD and
I'd really need some sort of incentive or whatever to entice me into
taking on a larger project of this nature.
The other issue of course is that add-on things are always inherently
more difficult to manage in a production environment, especially when
you've got a number of servers.
If NetBSD as a whole were to take on the challenge of switching whole-
heartedly to a more modularised and flexible system startup/shutdown
scheme then we'd at least have consistency between add-on packages and
the native system and things would integrate much easier.
Then if all are happy a full SysV compatible init(8) could be added too,
but without yet using it to implement the full "run-level" scheme (just
the current basic /etc/rc and /etc/shutdown and of course getty daemons)
and this would make it easier to support daemons that don't already have
their own ability to go into the background, and which might need
occasional restarts (eg. Squid). Indeed this step could be relatively
easily demonstrated with a pkgsrc module.
I.e. take NetBSD to basically the same state AT&T SysVr2.2 was in back
in 1986 as a first go, but of course with improvements to the details
along the way, such as perhaps a more rationalised and logical revamping
of login & session logging (perhaps required by an inittab style init
anyway), as well as perhaps some nice simple tools for making all this
stuff easier to visualise, monitor, and manage.
Then if the world hasn't blown up, and everyone's still basically happy
then we could discuss the sanity of converting daemons to run under
init; and becoming fully run-level compatible with Solaris or whomever
we look up to then; and so on.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>