Summary: | Hardware clock freezes until ntpd is killed on 11.2-RELEASE-p0 | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Danny McGrath <danmcgrath.ca> | ||||
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | New --- | ||||||
Severity: | Affects Only Me | CC: | cem | ||||
Priority: | --- | Keywords: | regression | ||||
Version: | 11.2-RELEASE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Danny McGrath
2018-07-30 11:07:53 UTC
Seen some more dmesg entries and had ntpq -p command time out trying to talk to the ntpd: +[702905] sonewconn: pcb 0xfffff80055cc8ae0: Listen queue overflow: 193 already in queue awaiting acceptance (10 occurrences) +[702906] Limiting open port RST response from 4646 to 200 packets/sec +[702966] sonewconn: pcb 0xfffff80055cc8ae0: Listen queue overflow: 193 already in queue awaiting acceptance (4885 occurrences) +[703027] sonewconn: pcb 0xfffff80055cc8ae0: Listen queue overflow: 193 already in queue awaiting acceptance (71 occurrences) +[703087] sonewconn: pcb 0xfffff80055cc8ae0: Listen queue overflow: 193 already in queue awaiting acceptance (68 occurrences) +[703131] swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131272, size: 12288 It's probably also worth noting that I am using PF on this host, and there seems to be a pattern of a port scan followed by a timeout. The current pf.conf isn't configured to allow any ntp packets in unless they are in the state table, if that helps anyone test things. I will see about running some tests later. I have pflogd enabled with a much longer retention period now, so hopefully I can get some captures on this. Odd, it's doing it again, and not only is ntp still running, but the time actually jumped backwards briefly: remote refid st t when poll reach delay offset jitter ============================================================================== +XXX.XXX.X.X (nt XXX.XX.XXX.XX 2 u 92 128 377 0.292 -0.098 0.057 *XXXX.XX.XX.XXX .GPS. 1 u 132 128 377 2.657 0.102 0.054 <pts/4|root|hostname|~ #> date Wed Aug 1 14:56:05 CEST 2018 <pts/4|root|hostname|~ #> date Wed Aug 1 14:56:06 CEST 2018 <pts/4|root|hostname|~ #> date Wed Aug 1 14:56:06 CEST 2018 <pts/4|root|hostname|~ #> date Wed Aug 1 14:56:05 CEST 2018 <pts/4|root|hostname|~ #> date Wed Aug 1 14:56:06 CEST 2018 The time keeps jumping back and forth, and ntpd -q is showing the exact same values. It's almost like ntpds' state is stuck and it's keeping the clock frozen. Sure enough, as soon as I stop ntpd, the time (as reported by date) continues to run. Any thoughts, anyone? Update: I disabled ntpd and tested running a simple ntpdate via cron. It's been almost two days now and the problem not only hasn't happened again, but the clock barely even drifted: 3 Aug 00:00:06 ntpdate[25890]: adjust time server xxx.xxx.x.x offset 0.003696 sec Anyway, seems clear that it was ntpd related already, but nice to eliminate stuff. So much for that idea. Seems another packet scan triggers it still while ntpd isn't running. I'll try narrow it down. About the only difference on this machine compared to other 11.2's is that this one gets some of the linux kld's loaded from I assume is poudriere. The pf.conf's are similar as well. Anyway, sorry for the noise! |