On Wed, Mar 19, 2003 at 05:15:02PM -0800, Andrew P. Lentvorski, Jr. wrote:
> Steve,
>
> I actually managed to pull down the dump. It doesn't have any lock
> requests in it. It looks like it is hanging in the rpcinfo call.
>
> If you really want to debug this, it's going to take a chunk of work
On Tue, Mar 18, 2003 at 05:25:36PM -0800, Andrew P. Lentvorski, Jr. wrote:
> On Tue, 18 Mar 2003, Steve Sizemore wrote:
>
> > root 399 0.0 0.1 263496 1000 ?? Is9:11AM 0:00.00 /usr/sbin/rpc.sta
> > root 402 0.0 0.1 1512 1156 ?? Ss9:11AM 0:00.00 /usr/sbin/rpc.loc
"Andrew P. Lentvorski, Jr." wrote:
> On Tue, 18 Mar 2003, Steve Sizemore wrote:
>
> > root 399 0.0 0.1 263496 1000 ?? Is9:11AM 0:00.00 /usr/sbin/rpc.sta
> > root 402 0.0 0.1 1512 1156 ?? Ss9:11AM 0:00.00 /usr/sbin/rpc.loc
> > daemon 405 0.0 0.1 1484 117
On Tue, 18 Mar 2003, Steve Sizemore wrote:
> root 399 0.0 0.1 263496 1000 ?? Is9:11AM 0:00.00 /usr/sbin/rpc.sta
> root 402 0.0 0.1 1512 1156 ?? Ss9:11AM 0:00.00 /usr/sbin/rpc.loc
> daemon 405 0.0 0.1 1484 1176 ?? I 9:11AM 0:00.00 /usr/sbin/rpc.l
On Tue, Mar 18, 2003 at 02:49:25PM -0800, Terry Lambert wrote:
> Steve Sizemore wrote:
> > I don't see now it could be "inter-program", since I've gone to great
> > lengths to simplify it to a single program failing on a brand new file.
>
> Is the file ever open by a program on the NFS server itse
Steve Sizemore wrote:
> I don't see now it could be "inter-program", since I've gone to great
> lengths to simplify it to a single program failing on a brand new file.
Is the file ever open by a program on the NFS server itself?
If so, this can cause the behaviour you are seeing (if you are
inter
"Andrew P. Lentvorski, Jr." wrote:
> On Mon, 17 Mar 2003, Terry Lambert wrote:
> Please don't speculate without having reviewed the code. It works because
> I rewrote rpc.lockd so that it does the required housekeeping itself.
> The FreeBSD lockd is the only open-source locking daemon that actuall
On Mon, Mar 17, 2003 at 11:36:58PM -0800, Terry Lambert wrote:
> Steve Sizemore wrote:
> > useful. As it is, it's still interesting. I have no way of judging the
> > quality of the code in question, other than the empirical result that
> > it works in most cases.
>
> Well, then you are stuck with
On Mon, 17 Mar 2003, Terry Lambert wrote:
> Actually, given this, I don't understand how FreeBSD server side
> proxy locking can actually work at all; it would incorrectly
> coelesce locks with local locks when the l_pid matched, which
> would be *all* locks in the lockd, and then incorrectly rele
Steve Sizemore wrote:
> Thanks for the explanation. If I were a programmer, it would be very
> useful. As it is, it's still interesting. I have no way of judging the
> quality of the code in question, other than the empirical result that
> it works in most cases.
Well, then you are stuck with the
Hi, Terry -
On Mon, Mar 17, 2003 at 07:02:31PM -0800, Terry Lambert wrote:
> "Andrew P. Lentvorski, Jr." wrote:
> > being sent is SETLKW which is a blocking wait until lock is granted. If
> > the server thinks the file is already locked, it will hang *and* that is
> > the proper behavior.
>
> It
"Andrew P. Lentvorski, Jr." wrote:
> The dump doesn't seem to be attached. However, I note that the request
> being sent is SETLKW which is a blocking wait until lock is granted. If
> the server thinks the file is already locked, it will hang *and* that is
> the proper behavior.
It is, to ensure
On Mon, Mar 17, 2003 at 01:21:19PM -0800, Andrew P. Lentvorski, Jr. wrote:
> On Sun, 16 Mar 2003, Steve Sizemore wrote:
>
> The dump doesn't seem to be attached. However, I note that the request
It appears that there are problems sending the raw dump. I've tried
twice - once 2 minutes after I se
On Sun, 16 Mar 2003, Steve Sizemore wrote:
> Sorry - I was trying to be too helpful. I actually did capture the raw
> dump but appended the decoded output. This time, I've attached a
> real raw dump.
The dump doesn't seem to be attached. However, I note that the request
being sent is SETLKW whic
On Sat, Mar 15, 2003 at 01:33:11AM -0600, Dan Nelson wrote:
>
> Oops. You appended a decoded dump again. I should have told you how
> to generate a raw tcpdump log. Add "-s 1500 -w file.pcap" to the
> tcpdump commandline. You won't get any output to the screen, but the
> raw packet contents wi
In the last episode (Mar 14), Steve Sizemore said:
> > That's ... odd. However, the Solaris rpc.lockd does some strange caching
> > that can lead to asymmetric behavior.
> >
> > In addition, you are running Solaris 2.5 which qualifies as practically
> > prehistoric in computer time. That's goin
On Fri, Mar 14, 2003 at 04:47:11PM -0600, Dan Nelson wrote:
>
> Ideally, a truss of the last 10 lines of the failing program plus the
> raw tcpdump log (run with -s 1500 so we get the whole packet) would be
> better. The truss is so we have proof that file locks are really to
> blame :)
>
On Fr
On Thu, 13 Mar 2003, Steve Sizemore wrote:
> Running RELENG_5_0 as nfs server with a Solaris 2.5 client.
> rpc.statd and rpc.lockd both running on FreeBSD, lockd and
> statd both running on Solaris. Locking a file (flock) works
> fine, but when an attempt to unlock it is made, the client
> session
In the last episode (Mar 14), Steve Sizemore said:
> On Fri, Mar 14, 2003 at 09:58:56AM -0600, Dan Nelson wrote:
> > In the last episode (Mar 13), Steve Sizemore said:
> > > Running RELENG_5_0 as nfs server with a Solaris 2.5 client.
> > > rpc.statd and rpc.lockd both running on FreeBSD, lockd and
On Fri, Mar 14, 2003 at 09:58:56AM -0600, Dan Nelson wrote:
> In the last episode (Mar 13), Steve Sizemore said:
> > Running RELENG_5_0 as nfs server with a Solaris 2.5 client. rpc.statd
> > and rpc.lockd both running on FreeBSD, lockd and statd both running
> > on Solaris. Locking a file (flock) w
In the last episode (Mar 13), Steve Sizemore said:
> Running RELENG_5_0 as nfs server with a Solaris 2.5 client. rpc.statd
> and rpc.lockd both running on FreeBSD, lockd and statd both running
> on Solaris. Locking a file (flock) works fine, but when an attempt to
> unlock it is made, the client se
Running RELENG_5_0 as nfs server with a Solaris 2.5 client.
rpc.statd and rpc.lockd both running on FreeBSD, lockd and
statd both running on Solaris. Locking a file (flock) works
fine, but when an attempt to unlock it is made, the client
session hangs. The program is typically (but not always)
unin
22 matches
Mail list logo
