On Tue, Jul 2, 2013 at 3:52 PM, Phil Pennock <[email protected]> wrote:
>
> The date(1) command on this thing can't parse the timestamp output by
> ls(1) and the ls(1) doesn't support using other formats for emission, so
> I ended up resorting to Python, because that's what I have installed.



It is worth pointing out that parsing the file may be a better route.
If the system clock is whacky and unbound updates the last queried
time in root.key the ctime on the file will also be whacky. Parsing
the root.key file might be the best option:

root.key:

;;last_queried: 1372768927 ;;Tue Jul  2 08:42:07 2013
;;last_success: 1372768927 ;;Tue Jul  2 08:42:07 2013
;;next_probe_time: 1372810779 ;;Tue Jul  2 20:19:39 2013
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640

Parsing last success seems like the most straightforward approach. The
first entry is a seconds since epoch so that should be readily
supported.  I want to suggest using something like the average of
last_success and next_probe but I am unable to come up with a clear
rationale.
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool

Reply via email to