random_seed - no locks available

[Peter Pentchev]

On Wed, May 01, 2013 at 03:44:09PM +0300, Peter Pentchev wrote:
> 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.

Just in case it wasn't clear, by "you" in these two paragraphs I am
referring to the original poster, M Russell, and not to Henry Hertz
Hobbit.

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
If there were no counterfactuals, this sentence would not have been paradoxical.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130502/e15231f2/attachment.sig>