Context is Issue #524, NTPsec daemon hangs after startup
The problem is that if configured with --enable-lockclock, ntpd doesn't work as a server if you don't activate the local clock driver in your ntp.conf. (It doesn't work as a client either.) ----------- There isn't any NTP documentation on lockclock or how to run a server in lockclock mode. Google finds that lockclock is an NIST algorithm, one of 3. The stuff I was looking at was pre-web, no links. I didn't try very hard - the NIST web site is in shutdown mode. Here is what I think is going on... (from reading the comments in our code) The basic idea is to trust the system time. The local clock driver uses ntp_adjtime to get the status of the system clock: OK, bad, leaping... If bad, it reports bad time which disables the server. The loop filter is setup to never change the system time. It watches the other servers specified in ntp.conf and declares itself dead if the local clock is not within the surviving clocks. ------------ I think we have 3 choices. 1) Drop it. 2) Support it. That includes documentation and testing. We could do testing by building a version of ntpd that use another port but otherwise did everything ntpd does. That would free up port 123 so we could run a lockclock mode server there. 3) Kludge things. I'm not sure what to do. I'm thinking of things like change --enable-lockclock to --enable-lockclock-and-I-know-what-I'm-doing and/or add a trap to make sure you have setup the local clock if built with ENABLE_LOCKCLOCK. I vote for dropping it. We can put things back together if we find a customer who wants it. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
