I wrote:
> Any ideas why ntpdate in the settime init file should take a long
> time (of order a minute), or ideas for debugging this?
Various people suggested ways that the network configuration would
affect this through routing or DNS not being set up at that point
(with some confusion between ntpdate and xntpd). However, I had
static routing and had already tried using IP numbers for the NTP
configuration, as I probably should have said, and the network
configuration is done earlier in the boot process. Avoiding
ntp{0,1,2} in production would defeat the object, of course.
Kevin Fleming probably gets the prize of an extra wizard's star he
doubtless doesn't need. He guessed “the network switch the tru64
boxes are connected to are still in a 'blocking' state after the
switch detected the LAN card was reset by the poweron / boot process”,
and they are connected to switches. I haven't yet been able to try
through a hub yet, but none of the other suggestions account for
what's happening. Thanks to other respondents anyhow.
[The reason it matters, apart from being annoying that you have to
wait extra minutes to get the system up, is that users having to
reboot the boxes have reasonably thought that something was hung.
I'll fix that with an extra message in the script.]
Received on Tue Feb 19 2002 - 17:00:26 NZDT