On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote: > On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote: > > ... > > Was there anything (at all) in /var/log/messages about ntpd? Even the > > routine messages (such as what interfaces it binds to) might give a bit > > of a clue about how far it got in its init before it died. > > .... > > Sorry; there might have been something yesterday... > If I do get another recurrence, I'll try to gather a bit more > information. > .... OK; got another one. This time, I have the complete /var/log/messages for a verbose boot, from that boot to just a bit after the ntpd crash; it's in <http://www.catwhisker.org/~david/FreeBSD/head>; as of the moment, that contains: [PARENTDIR] Parent Directory - [ ] CANARY 2015-03-22 10:03 15K [ ] CANARY.gz 2015-03-22 10:03 6.3K [ ] ntpd.core 2015-07-24 05:31 13M [ ] ntpd.core.gz 2015-07-24 05:31 124K [TXT] ntpd_crash_msgs.txt 2015-07-24 05:40 138K [ ] ntpd_crash_msgs.txt.gz 2015-07-24 05:40 19K This was running: FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #133 r285836M/285836:1100077: Fri Jul 24 05:24:41 PDT 2015 root_at_g1-245.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 Trying "gdb /usr/obj/usr/src/usr.sbin/ntp/ntpd/ntpd ntpd.core" still doesn't help much: This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. ... Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008011cd6a0 in sbrk () from /lib/libc.so.7 [New Thread 801c07400 (LWP 100133/<unknown>)] [New Thread 801c06400 (LWP 100132/<unknown>)] (gdb) bt #0 0x00000008011cd6a0 in sbrk () from /lib/libc.so.7 #1 0x00000008ccbd4f34 in ?? () #2 0x0000000000000005 in ?? () #3 0x0000000801800448 in ?? () #4 0x00000008011ca888 in sbrk () from /lib/libc.so.7 #5 0x00000008018000c8 in ?? () #6 0x00000008018000c0 in ?? () #7 0x0000000000000208 in ?? () #8 0x0000000801c32fb0 in ?? () #9 0x0000000000000001 in ?? () #10 0x0000000801cc20c8 in ?? () #11 0x0000000000000030 in ?? () #12 0x0000000801cc20c8 in ?? () #13 0x00007fffffffe480 in ?? () #14 0x00000008011cd240 in sbrk () from /lib/libc.so.7 #15 0x0000000000000280 in ?? () #16 0x00000008014bbc70 in malloc_message () from /lib/libc.so.7 #17 0x00000008018000c0 in ?? () #18 0x0000000801800448 in ?? () #19 0x0000000000000032 in ?? () #20 0x0000000801800458 in ?? () #21 0x00000008014bbc68 in malloc_message () from /lib/libc.so.7 #22 0x0000000801cc2000 in ?? () #23 0x00000008014bba60 in malloc_message () from /lib/libc.so.7 #24 0x0000000801cc20d8 in ?? () #25 0x00000000000000a0 in ?? () #26 0x0000000000000208 in ?? () #27 0x00007fffffffe4d0 in ?? () #28 0x00000008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) (gdb) I am presently suspecting that it's a bit dependent on ... well, "timing". I have my ~/.xsession set up so that once I've entered the passphrase(s) for my SSH private key(s), scripts start running to establish connections to other machines -- e.g., open an xterm locally, ssh over to my mailhub and (re-)establish a tmux session on that machine where I run mutt to read & write email (such as this message). While that almost always Just Works in stable/10, it's rather ... spottier ... in head -- I'd say it's about a 50% probability that it will work, vs. the ssh connection attempt hanging, and eventually timing out. But if I've waited (say) 30 seconds or so, I can establish such a connection easily. Granted, I am using wireless (802.11), but I get a sense that "things" are claimed to be "ready to go" a bit prematurely -- at least sometimes. Peace, david -- David H. Wolfskill david_at_catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC