Date:        Sat, 29 Dec 2001 11:21:41 -0500 (EST)
    From:        woods@weird.com (Greg A. Woods)
    Message-ID:  <20011229162141.AD68BB5@proven.weird.com>

  | That's something which should be there always anyway.

Perhaps - but in general which scripts get run at shutdown (and for that
matter at startup - though rc.conf control of on/off mostly avoids that
issue) is something that should be user configurable.   It is now - but
it is by editing rc.d scripts.

Or are you suggesting that no-one's system be permitted to run in anything
but the one true way?

  | That's a pretty big 'iff'....

No, it isn't - I have had reason to want things started in different
orders on a number of occasions.  Some of those were doubtless bugs
that should be (and I think have been) fixed - others were just my
perversity.

But some can't be done in one true way really.  Which comes first, ntpd
or named?   If it is named, then its initial measurements of the RTTs
to various servers might be skewed by the time adjustments made by ntpd
(or ntpdate) when it starts.  On the other hand, if ntpd (or ntpdate) is
run first, then I can't put names in ntpd.conf, only IP addresses (or the
names have to be in /etc/hosts) - which makes my config be at the mercy of
someone else's decision to renumber their systems.   There's no "right"
answer to this - which is important, if either, depends upon local
circumstances.

What's more, NetBSD currently (seems to) recognise this - ntpdate and
named are unordered with respect to each other in rc.d - so you kind of
get random choice as to which will start first.   That is, unless broken
by some other tie breaker - which appears (without going to study the code
in rcorder again) to be the lexical ordering of the names (ie: named comes
immediately before ntpdate in my system's startup order).

  | And how do you suggest the build do that without storing original copies
  | somewhere they won't be edited (eg. /etc/defaults/rc.d/*) so they can be
  | compared with the active copies in /etc/rc.d?

I didn't suggest that that could be done without doing that did I?

That's certainly an option (all the standard rc.d scripts together total
of the order of 100KB - a trivial volume).

But if that were too much, and at the expense of not providing the user
with a "what did I change in that script that stopped it being updated?"
mechanism, it could also be done by keeping md5 output of the scripts
(which then costs of the order of 5KB).

kre