Perl DBM script won't run

software development

#1

I am trying to run a Perl DBM script on Ganymede. I have tried several variants, including this simple one:

#!/usr/bin/perl

use Fcntl;
use AnyDBM_File;

%idx=();

tie %idx, “AnyDBM_File”, datafil, O_RDWR|O_CREAT|O_EXCL, 0644;
print “$!\n”;

$idx{“key01”}=“first value”;
$idx{“key02”}=“second value”;
print “keys written\n”;

untie %idx;
print “untied\n”;
#END END END END END

Perl always hangs up when I attempt to tie the hash to the database file (or when I call dbmopen, if I do it that way). It creates the file “datafil.pag” and then seems to choke. It runs fine locally, so I assume this is a permissions problem of some sort.

I would appreciate your help with this (almost certainly) newbie problem.

Thanks
-Mark


#2

This script does work on another remote linux host that I have access to, so it appears to be a problem specific to Dreamhost–a permissions issue, I suspect.

Any suggestions, other than “run it at the other host?”

Thanks
-Mark


#3

Does anything show up in the error log?

  • wil

#4

Nope. The problem occurs when I run the Perl script from the Unix shell command line. There is no log-able activity.


#5

[quote]Perl always hangs up when I attempt to tie the hash to the database
file (or when I call dbmopen, if I do it that way). It creates the file
"datafil.pag" and then seems to choke.

[/quote]

Maybe it’s having a problem with file locking, or some other problem with the dbm files. What happens if you run the script in /tmp instead of in your user directory? Does running:
% strace perl yourscript.pl

give you any idea of what it’s hanging on?


#6

Ok, it ran fine in /tmp. That’s a good start. Where do we go next?


#7

What about the strace output?

My guess is that there’s some sort of file locking problem, but hard to say for sure…

You could also send the path to the script to support and ask about it (maybe reference this thread as well).


#8

I sent the STRACE output to support earlier today. Here are the last few lines from the STRACE output:

open(“datafil.pag”, O_RDWR|O_CREAT, 0644) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, …}) = 0
fcntl64(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}

at which point the process froze again. Clearly, it’s having a problem opening that .pag file.

I sent the full path of the script to support.

Thanks
-Mark


#9

It looks like “Dream Ninja” was right. . .the process chokes when it requests a write lock on the file “datafil.pag”. Note the final line of the output:

open(“datafil.pag”, O_RDWR|O_CREAT, 0644) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, …}) = 0
fcntl64(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}

This is a problem in my user directory, but not in the /tmp directory. Does that indicate a permissions problem? Any idea on how it can be resolved?

Thanks
-Mark


#10

It most likely indicates a problem with NFS file locking on your machine.

It does look like the proper NFS utils are running, and portmapper seems to be doing OK:

ganymede: 09:00pm# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr
100024 1 udp 892 status
100024 1 tcp 895 status

Can you try something else for me? Can you leave the hung process sitting in one window, and try to run your script a second time in another window? Also, let the hung process sit there for at least 15 minutes and see if it ever completes.

I’ve seen some problems like this, where an fcntl lock fails the first time, but not the second. For example, if you create an mbox file and do:
mutt -f mboxfile
mutt will hang for a couple of minutes, and will give an error about not being able to lock the file. However, if you then run the same command from a second terminal, it works OK.

I have seen this happen to some users (with mutt, bogofilter, and other programs which lock using fcntl), but I haven’t had much luck figuring out what the exact problem is - maybe some obscure NFS bug.

To be clear, user home directories are mounted via NFS (network file system). /tmp is a local disk, which is why you’re not seeing the same problem in /tmp. You could (as a workaround) use a .lock file instead of fcntl locking, or else you could perform the operation in /tmp and copy the resulting files to your home dir.


#11

Yes, running a second window fixed the problem. The script locked up in the first window, but ran without trouble in the second. The script completed in the first window after four or five minutes, with an “unable to lock file” error. I then re-ran the script in the first window, and it immediately ran there as well, without problems.

Thanks for your help.
-Mark