Subject: Re: Changing root's shell to /bin/sh
To: None <jonathan@DSG.Stanford.EDU>
From: maximum entropy <>
List: tech-userlevel
Date: 03/17/1999 14:43:14
>Date: Wed, 17 Mar 1999 11:04:42 -0800
>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
>yes. but this amounts to running a `make' over the list of
>dependencies at every boot (possibly changing nothing if the dependencies
>are up-to-date).

It doesn't need to be that complex.  The decision-making process
doesn't need to know about dependencies, it just needs to determine if
the configuratioon has changed.  What I had in mind is more like:

# this is only a sample, not intended to be a real implementation
# of course it would really need to be written in C, both for speed
# and because cmp is in /usr/bin...
ls -l /etc/rc.d > /etc/
cmp /etc/ /etc/rc.d.files
if [ $? -ne 0 ]
	smart-program-to-rebuild-configuration > /etc/
	if [ $? -eq 0 ]
		mv /etc/ /etc/
		mv /etc/ /etc/rc.d.files
/bin/sh /etc/

``smart-program-to-rebuild-configuration'' would read all the
"require" and "provide" information from the scripts in /etc/rc.d, and
produce the startup script that would call all of them in the correct
order.  The decision-making process would be fast -- either the
configuration has changed or it hasn't.

>iirc, some developers objected fairly fiercely to that idea (not using
>make, but the idea of depending on the dependency-checker, crashes
>halfway through the `atomic' dependency-file update, etc, etc.).

Why is this different from a crash halfway through /etc/rc or
/etc/rc.conf?  The example given above would cause it to continue with
the old configuration.  Or it could just as easily drop out to single
user mode so you can fix it.

>Would it be a useful first step to take the existing monolithic
>/etc/rc, and break that up into sensible `modules'?
>While leaving  all the rc.conf machinery alone?

Maybe, but it might be difficult to determine what's sensible without
an implementation to test it against.


entropy -- it's not just a good idea, it's the second law.