lkml.org 
[lkml]   [1998]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: fcntl behaviour different in 2.1.129
Date
In muc.lists.linux-kernel, you wrote:
>Hi,
>
>we have a problem running an application built on 2.0.35 redhat. The
>application
>is running fine on 2.0.35, but not on the new kernel 2.1.129.
>
>our application is failing in fcntl(), for some reason.
>
>the system call tracing shows this output.
>
>fcntl(17, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1
>ENOLCK (No locks available)
>
>any ideas?

The local locking code only returns ENOLCK when no memory is available
(extremely unlikely, because then not much else would work). The other
possibility is that you are trying to lock a file on a NFS mounted volume.
The most common cause for this error then is when you are not running the
lockd daemon from the linux-nfs package/or the remote host is not running
a lockd.

2.0 did all NFS locking local, in 2.1 F_SETLK tries remote locking. If you
only want local locking convert to lockf().


-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.028 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site