Hi, On 09/30/15 11:47, Robert Blayzor via freebsd-security wrote:> Was this regression tested or missing more info? After updating and rebooting seeing a ton of problems with rpcbind core dumping at start.. lock manager fails to start, etc.Yes, this was tested specifically with NFS scenario for some time and was reviewed by several developers.> dmesg > da0: quirks=0x40<RETRY_BUSY> > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/da0p2 [rw].. > pid 367 (rpcbind), uid 0: exited on signal 6 (core dumped)Will it be possible for you to get a backtrace from the coredump? Cheers, -- Xin LI <delphij at delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20150930/a8c1f5e4/attachment.bin>
On Sep 30, 2015, at 3:10 PM, Xin Li <delphij at delphij.net> wrote:> > Will it be possible for you to get a backtrace from the coredump? > > Cheers,GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `rpcbind'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libwrap.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libwrap.so.6 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800d0164a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000800d0164a in thr_kill () from /lib/libc.so.7 #1 0x0000000800d01636 in raise () from /lib/libc.so.7 #2 0x0000000800d015b9 in abort () from /lib/libc.so.7 #3 0x0000000800d67f31 in __assert () from /lib/libc.so.7 #4 0x000000000040739a in ?? () #5 0x0000000000404075 in ?? () #6 0x000000000040303f in ?? () #7 0x000000080062a000 in ?? () #8 0x0000000000000000 in ?? () -- Robert inoc.net!rblayzor Jabber: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu
On Sep 30, 2015, at 3:10 PM, Xin Li <delphij at delphij.net> wrote:>> Was this regression tested or missing more info? After updating and rebooting seeing a ton of problems with rpcbind core dumping at start.. lock manager fails to start, etc. > > Yes, this was tested specifically with NFS scenario for some time and > was reviewed by several developers.I appear to have traced this back to when ypserv starts. rpcbind starts first, when ypserv starts, rpcbind core dumps. -- Robert inoc.net!rblayzor Jabber: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu
On Wed, Sep 30, 2015 at 12:10:47PM -0700, Xin Li wrote:> Hi, > > On 09/30/15 11:47, Robert Blayzor via freebsd-security wrote: > > Was this regression tested or missing more info? After updating and rebooting seeing a ton of problems with rpcbind core dumping at start.. lock manager fails to start, etc. > > Yes, this was tested specifically with NFS scenario for some time and > was reviewed by several developers. > ...FWIW, after updating my build machine (which acts as both an NFS client, obtaining access to certain file systems from a ReadyNAS, and as an NFS server, providing access to its /usr/src and /usr/obj during updates of "production" machines), I noted no problems -- and I have tested both roles on the machine. It was updated from: FreeBSD freebeast.catwhisker.org 10.2-STABLE FreeBSD 10.2-STABLE #1813 r288356M/288358:1002500: Tue Sep 29 04:15:28 PDT 2015 root at freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 to: FreeBSD freebeast.catwhisker.org 10.2-STABLE FreeBSD 10.2-STABLE #1814 r288411M/288418:1002500: Wed Sep 30 04:15:42 PDT 2015 root at freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64 And: freebeast(10.2-S)[13] service lockd status lockd is running as pid 582. freebeast(10.2-S)[14] ^lock^stat service statd status statd is running as pid 579. freebeast(10.2-S)[15] (Yes, I recognize that I'm running stable/10, while the OP is running ... releng/10, I think.) Peace, david -- David H. Wolfskill david at catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20150930/cf91af8f/attachment.bin>