[Kurt Roeckx] > Note that if you're trying to use ntpd to set the clock, it might > take several minutes before it first attempts to correct the clock, > so just depending on ntp is probably not going to give you the > behaviour you want.
I know. > Using something like rdate or ntpdate assumes the network is up and > you can reach a suitable ntp server, which isn't always the case. > You do not want to halt the whole boot process waiting for a timeout > of that, which is why we started running it in the background. So > depending on something like that is still not going to give you the > behaviour you want. With concurrent booting, only those init.d scripts needing $time will wait for it, which might not be all. But I understand this could be a problem if the NTP server isn't local on the network. When I used ntpdate, it always returned quickly, so I never have experienced this problem myself. > I think the hardware RTC is good enough for normal cases. The > kernel writes the RTC when ntpd is running. Assuming the hardware > properly keeps time while it's powered off, it's good enough. > > I also don't think it's useful to not log the message that ntpd > generates while it's starting. If I understand you correctly, you believe Debian should keep the non-LSB compliant behavoiur of $time? Is that correct? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
