On Sun, Sep 23, 2012 at 06:04:14AM -0700, David Wolfskill
wrote:> 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
root@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
root@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
root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>
> and that's the environment in which the above ktrace/kdump was
produced.
Try to revert the r240799. If this does not help, then some digging with
gdb would be needed to see why kernel dislikes the buffer. Well, the same
digging would be needed even if the revert helps.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120923/37b27cca/attachment.pgp