Ronan Flood wrote: > Harlan Stenn <[EMAIL PROTECTED]> wrote: > > >>The downside of your approach is that you'll have to keep making those >>changes with every upgrade. > > > Maybe you should just incorporate his changes and hope for the best :-/ > > Is it appropriate anyway for a refclock driver to terminate ntpd if it > isn't happy? From a quick look, only refclock_true and refclock_jupiter > call abort(), and only refclock_oncore and refclock_mx4200 call exit(). > All the others presumably mark the refclock "bad" in some way and allow > things to carry on, ignoring it. >
Maybe there should be a specification, perhaps in the new RFC, that says what to do if a refclock failure is detected. Marking the refclock "insane" comes to mind as a reasonable response. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
