Date: Tue, 1 Dec 1998 07:05:20 -0600 (CST) From: Richard Wackerbarth <rkw@nomad.dataplex.net> To: ADRIAN Filipi-Martin <adrian@ubergeeks.com> Cc: Eivind Eklund <eivind@yes.no>, hackers@FreeBSD.ORG Subject: Re: System V init (was: Linux to be deployed in Mexican schools; Where was FreeBSD?) Message-ID: <Pine.BSF.4.05.9812010627520.20091-100000@nomad.dataplex.net> In-Reply-To: <Pine.BSF.3.96.981201015637.4238K-100000@lorax.ubergeeks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Dec 1998, ADRIAN Filipi-Martin wrote:
> On Mon, 30 Nov 1998, Eivind Eklund wrote:
[...]
>
> While your code no doubt works and does the right think, I see two
> problems with it. First, it cannot be flipped through and explained in
> less than 10 minutes. While I can parse that fancy for-loop in the rc, I
> think this would send any newbie screaming for their mother. The old rc's
> aren't that opaque.
>
> Second, the dynamic ordering of dependencies is nice, but having
> the ordering information spread accross every file in rc.d makes it very
> hard to speak with authority on just what is going to happen and in what
> order. Pulling this ordering information up into a central place would be
> much prefered. I also content that it would be more maintainable over the
> long haul.
>
> I'd argue more for maintaining a list of rc's to run in rc.conf or
> the top level rc itself. Something like the following:
>
> scripts=""
> scripts="${scripts} ccdconfig"
> scripts="${scripts} swapon"
> scripts="${scripts} autoboot"
> scripts="${scripts} mount_root"
> scripts="${scripts} mount_local"
> scripts="${scripts} start_net"
> scripts="${scripts} mount_nfs"
> ...
> scripts="${scripts} rc.local"
>
> for i in ${scripts}; do
> /etc/rc.d/$i start
> done
>
> The order of execution is easily grasped. For rc.shutdown, all
> you need to do is reverse the list and loop with "stop" as the argument.
>
> If you still want to do a tsort, add the before and after values
> at this level, where they are easily understood. At least then the
> dependencies are quicker to see.
Perhaps we can get the benefits of both approaches by having a script that
auto-generates the script inclusion script.
[ in /etc/rc ]
...
. /etc/rc.conf
if [ X"auto_sequence_scripts_enable" = X"YES" ] ; then
/etc/rc.rebuild_script_sequence
fi
. /etc/rc.script_sequence
- - -
[ in /etc/rc.rebuild_script_sequence ]
[A variant of Eivind's code whech generates ...]
- - -
[ in /etc/rc.script_sequence ]
lines (in the desired order) such as
. /etc/rc.d/network1
/usr/local/etc/rc.d/apache start
- - -
I see a few complaints about this scheme.
1) It certainly is a lot of effort to handle
the common case where the startup script is
so short that it nomally included inline.
2) This scheme would require that the /etc/rc.script_sequence file
be writeable.
3) We need a scheme that automatically defaults scripts
which have no sequencing info to the end of the sequence
4) We need to be able to postpone major portions of the
sequence until external events occur. In particular, consider
PCMCIA ethernet interface cards that "appear" some time after
the card deamon is started. We need to delay network services
until the card appears. Further, we may need to delay ntpdate
until a default route has had time to be discovered.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9812010627520.20091-100000>