random_seed - no locks available

[brewsome]

Thanks for the responses.  I did find out that the home drive is a NFS
mount.  NFS is version 3, and I don't see any nolock option specified in
/etc/fstab.  It appears that NFS is mounted properly.  I'm thinking it might
be a NFS problem too, but not sure were.  I'll dig into that side more.

Date: Wed, 1 May 2013 15:44:09 +0300
From: roam at ringlet.net
To: hhhobbit at securemecca.net
Subject: Re: random_seed - no locks available
CC: gnupg-users at gnupg.org

On Mon, Apr 29, 2013 at 09:29:58PM +0000, Henry Hertz Hobbit wrote:
> On 04/29/2013 02:43 PM, M Russell wrote:
> > Hello,
> > 
> > I hope someone might be able to lend me a hand.  I am running
> > into an error message that I resolve.  I get a lock error when
> > trying to encrypt or decrypt a file.  I found other forums
> > that suggest deleting the random_seed file and killing the rpm
> > process, but I don't have a rpm process running.  Renaming the
> > file allowed the system to recreate the random_seed file, but
> > the error persists.  I have noticed the file size is 0 which
> > would be appropriate since the file cannot be locked.  An
> > strace shows the error message, but it doesn't appear to point
> > anything else out.  A lsof doesn't show the file is open.  I'm
> > not sure where else to look.  Has anyone seen this and have any
> >  suggestions?
> > 
> > I'm running centos 6.2, gnupg 2.0.14, libgcrypt 1.4.5
> > 
> > can't lock `/home/mruss/.gnupg/random_seed': No locks available
> > note: random_seed file not updated
> > 
> > 
> > open("/home/mruss/.gnupg/random_seed", O_RDONLY) = 10
> > fcntl(10, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1
ENOLCK (No locks available)
> > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
> > open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
> > open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
> > open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
> > open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
> > open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
> > write(2, "can't lock `/home/mruss/.gnupg/random_seed': No locks
available\n", 68) = 68
> > close(10)                               = 0
> 
> Note that random_seed is opened RDONLY.  The lock is just for
> reading and it is non-blocking.  Why it should be there at
> all when you are really locking nothing (len=0) is a bit of
> a mystery.  The length was probably set from a file stat.
 
Werner already replied on this one - len == 0 has a special meaning and
should indeed be correct here.
 
> There are basically three reasons for errno to be set to ENOLCK:
> 
> 1. You are out of lock table space (most likely).  Closing down
>    everything and then rebooting is perhaps the best way to
>    return sanity to the world.
> 
> 2. You have too many segment lockdowns.  What segements?
>    Notice that the length is zero.
> 
> 3. Something like an NFS system problem.  That probably is not
>    applicable.
 
Actually this would be my first question to the original poster - is
there any chance that your home directory is remotely mounted using NFS
or some other remote filesystem protocol for which your kernel does not
really support file locking?  (I have seen quite some usage of user home
directories exported via NFS in shared environments, e.g. universities)
 
If it is NFS, you might want to look into enabling file locking using
something like the "nfslock" service, rpc.lockd or something similar on
both the client and the server, just in case.
 
G'luck,
Peter
 
-- 
Peter Pentchev roam at ringlet.net roam at FreeBSD.org p.penchev at storpool.com
PGP key:       http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
This sentence contradicts itself - or rather - well, no, actually it
doesn't!


_______________________________________________ Gnupg-users mailing list
Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130501/9545dfab/attachment-0001.html>