Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Re: flock, not unflocking

by kael (Monk)
on Feb 15, 2001 at 11:14 UTC ( [id://58577]=note: print w/replies, xml ) Need Help??


in reply to Re: flock, not unflocking
in thread flock, not unflocking

I'm doing :
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)

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

    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.

      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")

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://58577]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (4)
As of 2024-04-24 19:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found