kael has asked for the wisdom of the Perl Monks concerning the following question:
Ok, what can cause flock to not unflock when the program ends? I was always told that it unlocked the file with the program ended, but this doesn't seem to always be the case.
So how do I keep my programs from doing this, and how can I unflock a file when this happens? (The only way I've found is to make a copy, delete the original and copy back)
This has been a major pain, since I can't figure out the cause and it causes the next program get stuck waiting for the lock to be released.
Help would be apreciated.
Re: flock, not unflocking
by merlyn (Sage) on Feb 15, 2001 at 10:57 UTC
|
but this doesn't seem to always be the case.
Well, since your question doesn't yet make sense, I have to ask my standard "help desk" response to that which is:
How do you know?
What's your test case? What have you ruled out, and how?
-- Randal L. Schwartz, Perl hacker
| [reply] |
|
print "flocking now\n";
flock (FILE, 2);
print "done flocking\n";
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
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)
| [reply] [d/l] [select] |
|
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
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] |
|
Re: flock, not unflocking
by flocto (Pilgrim) on Feb 15, 2001 at 18:26 UTC
|
Well, if your program doesn't release the lock by itself, just make sure your filehandle is unlocked by yourself..:
END
{
flock (FILEHANDLE, 8);
#or, more general:
#flock (FILEHANDLE, LOCK_UN);
}
Regards,
octopus
--
GED/CC d-- s:- a--- C++(+++) UL+++ P++++$ L++>++++ E--- W+++@ N o? K? w-- O- M-(+) V? !PS !PE !Y PGP+(++) t-- 5 X+ R+(+++) tv+(++) b++@ DI+() D+ G++ e->+++ h!++ r+(++) y+ | [reply] [d/l] [select] |
|
| [reply] |
|
| [reply] [d/l] |
Re: flock, not unflocking
by ncw (Friar) on Feb 15, 2001 at 19:18 UTC
|
If you are running on Linux you might find the contents of the file /proc/locks
useful. Here you can see all the locks all processed on
which files. You'll probably find ls -i helpful as
well to turn file names into inodes when looking at the
output. | [reply] |
Re: flock, not unflocking
by ftforger (Sexton) on Feb 15, 2001 at 20:49 UTC
|
First, something that has been implied but not stated
outright:
What O/S are you using. Some do not do flock properly.
Second, since your example says its doing the lock first
and then attempts the lock, but never prints the 'done'
message (you said it locks up after printing the message)
I would say that something else may be wrong with how you
are attempting the flock, OR something else has the file
locked and your program is waiting to acquire the lock. | [reply] |
|
|