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

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.

Replies are listed 'Best First'.
(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]

In Section Seekers of Perl Wisdom