Bug 238352 - ntpd fails to log fatal error(s)
Summary: ntpd fails to log fatal error(s)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-05 22:16 UTC by Ronald F. Guilmette
Modified: 2019-06-21 04:12 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald F. Guilmette 2019-06-05 22:16:32 UTC
The man page for ntpd(8) and specifically the portion dealing with the -g option, says explicitly:

   "Normally, ntpd exits with a message to the system log if the offset
   exceeds the panic threshold..."

In my experience, this appears not to be the case.  Many ntpd messages *do* end up in /var/log/messages, but when and if ntpd experiences a situation where the difference between the currently set time and the actual time (as provided by the configured remote ntp servers) is larger than the "panic threshold" then ntpd will exit, as expected, but when it does so it appears that it is NOT actually writing any message or messages first to the syslog and/or to /var/log/messages.

If this can be reproduced, it should be fixed.  The ntpd daemon should have the common courtesy to let the user know, via the syslog, that it has decided to commit suicide, and the reason for that decision.  This information is vitally necessary in order for the user to understand and then rectify the underlying problem.
Comment 1 Ronald F. Guilmette 2019-06-05 22:39:48 UTC
I have just been informed that this is a known bug in the ntpd reference sources, and that patch(es) have already been proposed, some years ago, in fact, but for some unknown reasons, those appear to have been sat on and ignored, for several years now, by the ntpd reference code maintainers...

https://bugs.ntp.org/show_bug.cgi?id=1130
https://bugs.ntp.org/show_bug.cgi?id=2410

I see no reason why their inaction should prevent this evident and annoying problem from being properly fixed in the FreeBSD code base.