random_seed - no locks available

[Henry Hertz Hobbit]

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.

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.

If you want to test for the first this may or may not work
since I am almost asleep and am REALLY rusty on my use of
fcntl for file locking:

http://www.securemecca.com/public/GnuPG/TestLock/

Pick your own zip poisoning.  If you get lucky and the program
tells you that you have a locking problem then you are probably
out of available file locks.

In any case I don't know what work-around gnugpg 2.0.14 has for
this particular case or if it has one.  It probably does have
a work-around.

Do you still have the old random_seed file?  If so, after
rebooting I would put it back in place and make sure it has
the proper permissions.  The Read flags and eXecute flag on
the directory are probably okay since you can open the file
for reading.   Just make the sure the Write flags are also
set.  If one of the write permisions is turned off that could
explain a zero length file.

$ cd
$ umask
0077
$ ls -al | grep gnupg
drwx------  3 USER_NAME GROUP_NAME    4096 Apr 29 19:32 .gnupg
$ cd .gnupg
$ ls -l random_seed
-rw------- 1 USER_NAME GROUP_NAME 600 Apr 29 16:59 random_seed

My bet is your lock table space is filled up so closing down and
rebooting with your old random_seed file set to the proper
permissions will cure the problem.

NAP TIME!