Xref: utzoo comp.protocols.nfs:2251 comp.unix.internals:2683
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!pcserver2!genesis!kdenning
From: kdenning@genesis.Naitc.Com (Karl Denninger)
Newsgroups: comp.protocols.nfs,comp.unix.internals
Subject: Re: lockf, NFS, and file locking issues
Summary: If you're on a Sun....
Message-ID: <1991May2.032626.25228@pcserver2.naitc.com>
Date: 2 May 91 03:26:26 GMT
References: <1991May1.165813.17465@xn.ll.mit.edu>
Sender: news@pcserver2.naitc.com (Usenet admin)
Organization: AC Nielsen Co., Bannockburn IL
Lines: 39
Nntp-Posting-Host: genesis.naitc.com

In article <1991May1.165813.17465@xn.ll.mit.edu> rkc@xn.ll.mit.edu writes:
>=This is a slight modification of a posting that has occured elsewhere.
>=It was suggested that I post these questions to these newsgroups.
>
>I have written an application that is similar to a network database
>application in which data is stored in on NFS-accessable file.  To protect
>from multiple simultaneous updates, I have used the lockf subroutine to lock
>the entire file.  I have had numerous problems with the lockf routine "locking
>up".  The symptoms vary:
>
>	S1. The client dies and the server doesn't realize it.  In order to
>	avoid processes being killed when they own the lock, I catch the
>	following signals: 
>
>	S2. Sometimes the client doesn't die--it just hangs.  Attaching the
>hung program indicates something hangs inside of fcntl.
>
>	S3. Occasionally, I get messages like 
>		unknown klm_reply proc(0)
>		unknown klm_reply proc(40)
>
>	Does anyone have any idea where these come from?

Heck, you're fortunate.

If it's a Sun you're on, get on the horn with them and raise HELL.  Sun
hasn't had a working lockd in their OS for at least three releases that I
know of (4.03, 4.1, and now 4.1.1).  Their patches fix some of the bugs, and
break other things.

In short, yes, it's broke.  Call the vendor and make a stink.

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning@nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.