Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Dec 2005 09:43:54 +0100
From:      Michael Sperber <sperber@informatik.uni-tuebingen.de>
To:        freebsd-stable@FreeBSD.ORG
Cc:        Oliver Fromme <olli@lurza.secnetix.de>
Subject:   Re: mountd fails intermittently
Message-ID:  <y9loe3he8j9.fsf@informatik.uni-tuebingen.de>
In-Reply-To: <200512150943.jBF9habb049585@lurza.secnetix.de> (Oliver Fromme's message of "Thu, 15 Dec 2005 10:43:36 %2B0100 (CET)")
References:  <y9l7ja6kf1l.fsf@informatik.uni-tuebingen.de> <200512150943.jBF9habb049585@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help

Oliver Fromme <olli@lurza.secnetix.de> writes:

> Michael Sperber <sperber@informatik.uni-tuebingen.de> wrote:
>  > Oliver Fromme <olli@lurza.secnetix.de> writes:
>  > > That looks like your rpcbind(8) process died.  Can you
>  > > check that with ps?  Also, are there any warnings or
>  > > errors reported in /var/log/messages?
>  > 
>  > No, it's still running.  It shows up in rpcinfo (as does nfsd),
>
> But mountd does not show up there?

It shows up, too.  It just doesn't respond to pings.

> Now the one question is:  What are the circumstances under
> which the problem can be reproduced?  :-)   Of course I'm
> aware that that's probably a tough question.

It's pretty reproducible: A mount attempt from my one problematic
client will do it.

> 1.  First of all, it might be helpful to see the contents
>     of your /etc/exports.  To be honest, I don't think that
>     it is causing the problem, but you never know.

/storage/disk1 192.168.1.100 <a bunch of other IPs>

> 2.  Does your mountd log anything to /var/log/messages?
>
No.

> 3.  What flags are you using with rpcbind and mountd, 

rpcbind: no flags
mountd: -r (but problem shows up without it, too)

> if
>     any?  What flags are you using with the mount command
>     line (i.e. anything unusual)?

No flags:

mount_nfs matt://storag/disk1 <mountpoint>

> 4.  Please post the output from these commands (preferably
>     before failure and after failure, if possible):
>     # rpcinfo
>     # sockstat | egrep "mountd|rpc"

Hrm.  I see that just running these commands (on the server) pretty
reliably puts it into failure mode.  So here's the output from one
run:

   program version netid     address                service    owner
    100000    4    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    3    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    2    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    4    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    3    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    2    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    4    tcp6      ::.0.111               rpcbind    superuser
    100000    3    tcp6      ::.0.111               rpcbind    superuser
    100000    4    udp6      ::.0.111               rpcbind    superuser
    100000    3    udp6      ::.0.111               rpcbind    superuser
    100000    4    local     /var/run/rpcbind.sock  rpcbind    superuser
    100000    3    local     /var/run/rpcbind.sock  rpcbind    superuser
    100000    2    local     /var/run/rpcbind.sock  rpcbind    superuser
    100003    2    udp       0.0.0.0.8.1            nfs        superuser
    100003    3    udp       0.0.0.0.8.1            nfs        superuser
    100003    2    udp6      ::.8.1                 nfs        superuser
    100003    3    udp6      ::.8.1                 nfs        superuser
    100003    2    tcp       0.0.0.0.8.1            nfs        superuser
    100003    3    tcp       0.0.0.0.8.1            nfs        superuser
    100003    2    tcp6      ::.8.1                 nfs        superuser
    100003    3    tcp6      ::.8.1                 nfs        superuser
    100005    1    udp       0.0.0.0.3.247          mountd     superuser
    100005    3    udp       0.0.0.0.3.247          mountd     superuser
    100005    1    tcp       0.0.0.0.2.99           mountd     superuser
    100005    3    tcp       0.0.0.0.2.99           mountd     superuser
    100005    1    udp6      ::.3.246               mountd     superuser
    100005    3    udp6      ::.3.246               mountd     superuser
    100005    1    tcp6      ::.2.98                mountd     superuser
    100005    3    tcp6      ::.2.98                mountd     superuser
root     mountd     72379 4  udp4   *:1015                *:*
root     mountd     72379 7  tcp4   *:611                 *:*
root     mountd     72379 8  udp6   *:1014                *:*
root     mountd     72379 9  tcp6   *:610                 *:*
root     rpcbind    54162 4  udp6   *:*                   *:*
root     rpcbind    54162 7  stream /var/run/rpcbind.sock
root     rpcbind    54162 8  udp6   *:111                 *:*
root     rpcbind    54162 9  udp6   *:642                 *:*
root     rpcbind    54162 10 tcp6   *:111                 *:*
root     rpcbind    54162 11 udp4   *:111                 *:*
root     rpcbind    54162 12 udp4   *:673                 *:*
root     rpcbind    54162 13 tcp4   *:111                 *:*


> 5.  If all else fails, maybe tracing the mountd process
>     during a failing mount attempt might be helpful.
>     Personally I prefer strace (from the ports collection)
>     for the more useful output, but you can also use ktrace
>     which is in the base system.

I'll try that sometime over the weekend.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y9loe3he8j9.fsf>