From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Christian Reis <kiko@async.com.br>
Cc: NFS@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: 2.4.19+trond and diskless locking problems
Date: 04 Oct 2002 00:47:38 +0200 [thread overview]
Message-ID: <shsy99f16np.fsf@charged.uio.no> (raw)
In-Reply-To: <20021003184418.K3869@blackjesus.async.com.br>
>>>>> " " == Christian Reis <kiko@async.com.br> writes:
> When this happens, there is always a file left in
> /var/lib/nfs/sm (normally there are no files in there for none
> of the clients, even when they are on) for the hanging box. Is
> this normal?
It means that rpc.statd did not manage to unmonitor the NFS locks
before it shut down. The reasons for this could be multiple, such as
for instance if the client crashed and/or rebooted. It might also
indicate that the server could not be contacted in order to unmonitor
the lock.
> We also occasionally get a log message in the server for this
> box like:
> kernel:Aug 10 17:39:22 anthem kernel: lockd: cannot monitor
> 192.168.99.7
Means that the kernel was unable to contact rpc.statd, or that was
unable to contact the server's rpc.statd for some reason.
> Trond, can I get you more troubleshooting information, or
> should I try 2.4.20-pre on server *and* clients? This is a bit
> wierd, but since I don't know a lot of what went on in the last
> changes, I'm not sure where to start looking.
There is nothing in the above to suggest that this must be a kernel
problem. The fact that you are seeing files in /var/lib/nfs/sm
in these cases rather suggests that the problem lies with rpc.statd.
Can you see any reason in your setup why it should be failing?
Cheers,
Trond
next prev parent reply other threads:[~2002-10-03 22:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-03 21:44 2.4.19+trond and diskless locking problems Christian Reis
2002-10-03 22:47 ` Trond Myklebust [this message]
2002-10-03 23:26 ` Christian Reis
2002-10-04 1:13 ` Trond Myklebust
2002-11-20 14:02 ` Christian Reis
2002-11-20 17:02 ` Trond Myklebust
2002-11-27 0:41 ` Christian Reis
2002-11-27 1:14 ` Trond Myklebust
2002-11-27 1:44 ` Christian Reis
2002-11-27 17:08 ` Christian Reis
2002-11-27 20:31 ` Trond Myklebust
2002-11-29 1:34 ` Christian Reis
2002-12-02 14:51 ` Christian Reis
[not found] ` <20021128232911.G18175@blackjesus.async.com.br>
[not found] ` <200212021921.24330.trond.myklebust@fys.uio.no>
2002-12-04 14:20 ` Christian Reis
2002-11-27 1:01 ` Christian Reis
2002-10-04 7:07 ` [NFS] " Juergen Hasch
2002-10-04 13:17 ` Christian Reis
2002-10-04 16:00 ` Juergen Hasch
2002-10-04 16:00 ` [NFS] " Juergen Hasch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=shsy99f16np.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=NFS@lists.sourceforge.net \
--cc=kiko@async.com.br \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.