[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NetBSD style rc.d scripts?
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: NetBSD style rc.d scripts?
- From: Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>
- Date: Mon, 20 Jan 2003 21:52:00 -0500
"Paladdin" <guardame_el_secreto_(_at_)_yahoo_(_dot_)_es> writes:
> No -I hope!- :) Does somebody think there are some really good reason to =
The usual reason to do so would be to take all the
tests that look something like this:
#if [ -x /usr/local/sbin/snmpd ]; then
# echo -n ' snmpd'; /usr/local/sbin/snmpd
and replace it with per-service startup files.
That way, there's no need to have random shell script hackery to decide
which services are enabled, or scary script editting to delete or
update script logic which is no longer functional or out of date.
Instead, you could have a simplier uniform interface for your packages
to decide which services need to be start (& stopped) on a system
Another reason to do this would be to support having special
per-service shutdown code (rather than making the service trap SIGTERM
and decide what to do).
Doing any of this really means replacing /etc/init with something that
knows about system V init semantics and run levels. That's probably
not too useful unless you can come up with a reason why having more
than two run states (single-user, multi-user) is useful. (And to make
that useful, you'd have to have all packages know whatever new
divisions in functionality you made.) Presumably you'd also want to
replace utmp.h with the augmented system V structure. You'd also have
to decide how to handle kern.securelevel.