This (rpc.lockd exiting rather quickly) is happening on my home "build machine"; in hindsight, the first symptom I saw was from the cron-initiated attempt to perform "svn update" on the NFS-resident /usr/ports:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/usr/ports' is an old development version (format
12); to upgrade it, use a format 18 client, then use
'tools/dev/wc-ng/bump-to-19.py', then use the current client
which, I admit, confused me a great deal for a while.
The machine in question is intended to do this every night -- and
the preceding night, there was no problem, so while I didn't actually
check explicitly to verify that rpc.lockd was running, /usr/ports
did get updated.
I tried "sh -x /etc/rc.d/lockd restart", which wasn't exceptionally
revealing, except to verify that I was trying to start rpc.lockd with no
arguments.
So I did "ktrace -di /usr/sbin/rpc.lockd"; here's a cut/paste of the
last page or so of the resulting kdump output:
...
2336 rpc.lockd CALL connect(0x3,0xbfbfce30,0x6a)
2336 rpc.lockd STRU struct sockaddr { AF_LOCAL, /var/run/logpriv }
2336 rpc.lockd NAMI "/var/run/logpriv"
2336 rpc.lockd RET connect 0
2336 rpc.lockd CALL sendto(0x3,0xbfbfd388,0x27,0,0,0)
2336 rpc.lockd GIO fd 3 wrote 39 bytes
"<30>Sep 23 05:38:34 rpc.lockd: Starting"
2336 rpc.lockd RET sendto 39/0x27
2336 rpc.lockd CALL sigaction(SIGALRM,0xbfbfdc70,0)
2336 rpc.lockd RET sigaction 0
2336 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x2841d0c0)
2336 rpc.lockd RET nlm_syscall -1 errno 14 Bad address
2336 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x2806ee0c,0xbfbfda88)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x2806ee20,0)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x2806ee0c,0xbfbfd208)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x2806ee20,0)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x2806ee0c,0xbfbfd208)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x2806ee20,0)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x2806ee0c,0xbfbfd208)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x2806ee20,0)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x2806ee0c,0xbfbfd208)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x2806ee20,0)
2336 rpc.lockd RET sigprocmask 0
2336 rpc.lockd CALL exit(0x1)
I've attached a gzipped copy of the complete file in case that's
of interest or use.
When lockd was last working, the machine was running:
FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #474
240772M: Fri Sep 21 05:03:35 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
Last night, it was running:
FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #475
240811M: Sat Sep 22 05:02:51 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
and after updating this morning, it is now running:
FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #476
240856M: Sun Sep 23 05:10:13 PDT 2012
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
and that's the environment in which the above ktrace/kdump was produced.
I guess I hold off on my port-rebuilding for the "production"
machines that I recently switched from stable/8 to stable/9 until
next weekend (as they use the /usr/ports that I can't update)....
I've also attached a copy of the dmesg.boot, in case that helps.
Any ideas?
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
dmesg.boot.9.1-PRERELEASE.gz
Description: Binary data
lockd.kdp.gz
Description: Binary data
pgp41EiJ1SwPx.pgp
Description: PGP signature
