Re: Re: flock, not unflocking

I'm doing :

print "flocking now\n";
flock (FILE, 2);
print "done flocking\n";
[download]

it prints flocking now . and freezes. If I make a copy of the file, delete the original, and then copy the copy back to the original name like so:

copy foo bar
rm foo
copy bar foo
rm bar
[download]

It'll work again but only for a while then it goes back to stopping at the flock. Using ps -A I don't see any other programs running which would flock the file.
After fiddling with it for far too long, it seems to be caused by Apache timing out. This is in a cgi script. For some reason when Apache kills it off the flock isn't undone. (near as I can figure)

Comment on Re: Re: flock, not unflocking Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: flock, not unflocking by repson (Chaplain) on Feb 15, 2001 at 13:08 UTC
If apache is killing the cgi/perl process with a signal such as SIGINT, then the perl garbage collector may not be running, so it will never run `close(FILE)` (or equivilent) which would automatically unflock the file. What you need to do is eithier tell your program to ignore the signal or give it something to do when it recives the signal. Perl's signal handlers aren't reliable, so you should possibly go with the first method. `$SIG{INT} = 'IGNORE'; # ignore signal and keep on going, but without a + connection to your user $SIG{INT} = sub { die "Received SIGINT\n" }; # normal exit with an err +or` [download] I have no idea if doing that would solve your problem, but fiddling around with signal handlers in apache and on the command line might answer that question.	[reply] [d/l] [select]
(tye)Re: flock, not unflocking by tye (Sage) on Feb 15, 2001 at 20:38 UTC
No! The operating system will close a file when the process goes away even if Perl is killed with signal 9 (SIGKILL) and so doesn't get a chance to even think about cleaning up. And this will release the lock. If a lock still exists then there is a process that still has the file open or you have a bug in your operating system. Perhaps the original problem has to do with mod_perl and so there is no separate process and it is Apache itself that still has the file open. I don't know enough about mod_perl but I doubt that a %SIG trap would help this problem. I'm also doubtful (but less so) that an `END` block would get called in this case and fix the problem (though that would be a neat trick for mod_perl). - tye (but my friends call me "Tye")	[reply] [d/l]