The only problem with this type of an approach is if the guts of your script are long and complex, having multiple exit points or failure modes, such as "do this or die" or "do this or croak". It gets even worse if you are using some other module which has a "do or die" type function. This way your program will exit without cleaning up the lockfile.

So, the obvious solution to this is to put the lockfile cleanup into an END block. However, even that will not work all the time. For example, if you are using a module which was compiled from an XS and that module takes a core dump, you will leave the lockfile behind.

All this is to say that lockfiles have their weaknesses. One way to overcome these flaws is by trying to run your program and checking the presence of the lockfile for, say, average duration of script times a factor of 2. This way, if the lockfile still exists, then it must be a stray file which should be deleted so the script can run.

Won't Perl release open file handles when it exists? Even in a die or croak when the script exists it will lose the lock.

-- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier

Good points, thanks. I think the problem with dying scripts can be striked by checking the saved PID as ruoso suggested. Well, then one should be sure not to leave zombies, I'd guess.

---

Ordinary morality is for ordinary people. -- Aleister Crowley

The standard way of doing that is creating a lockfile which contains the pid of the proccess. The proccess will remove the file when exit.

When checking, the new instance will see if the file exists, and if exists, check if the pid stored in the file is still alive (a kill -0 $pid will do it).

If, for some reason, the last proccess didn't remove the lockfile, it will be detected and the next proccess will continue, overriding the lockfile.

die "a horrible death" if ( -f "lockfile");

open LOCK, ">", "lockfile" or die;
close (LOCK);

... do some stuff ...

unlink("lockfile");
[download]

Nice race condition you've managed to write there. If you're going to try and roll your own make sure you do it correctly with sysopen and O_WRONLY|O_EXCL. See the docs, specifically perldoc -f sysopen and perldoc perlopentut.

Probably not ideal, but this is almost a not too bad method when you know that separate instances of the same program will always start not less than a minute apart. There should be no race conditions. But if for some reason the previous instance never unlinks the file, no subsequent instance will run, which may or may not be what you want. Or if you manually start up the process at the same time cron kicks it off, you may run into a race condition. It may be best to open the file unconditionally and then use lock to get an exclusive lock on the file. Or use one of the previously mentioned modules to do that for you.

I'll also mention that we do that sort of thing alot in our shell scripts, but it's the only solution since we can't call lock from the shell (also perl is not installed on many of our customer's systems). Unfortunately, we also use this method in shell scripts outside of cron where race conditions are possible, and some sort of file lock would be better.

#!/bin/sh
(while true
do
<script>
sleep 60
done ) &
[download]