You could use a pid file for that. This is, as far as I know, the mechanism commonly used by server software.

Um, yes, but that still has race conditions AND problems with reboots AND problems with programs crashing before they can remove their PID file.

In short, PID files suck. Many people believe they are needed or at least useful, but they aren't. They were never a good idea, but nobody had a better solution for years. The better approach for managing service software is to have a monitoring process. AFAIK, djb's deamontools are the earliest solution for getting rid of PID files, and many other solutions copied that idea, including systemd. Yes, systemd may still create PID files for legacy reasons, but like with deamontools, they are no longer needed.

For the Highlander problem ("there can be only one"), a PID file might work often, but there is no guarantee that it will always work. On Unix systems (Linux, BSD, ...), getting a lock on the executable is the most robust solution, as long as you stay away from non-native and networking filesystems. See Re^2: Mechanism for ensuring only one instance of a Perl script can only run?.

Alexander

Maybe I'm overlooking something, but given the following example code, it is not clear to me where there could occur a race condition.

#! /usr/bin/perl                                                      
+                                   
use strict;
use warnings;

my $pidfile="testfile.pid";
my $scriptname = $0;
my $pid="$$";

if(-e $pidfile)
{
    open(PFH, '<', $pidfile) or die $!;
    $pid =<PFH>;
    close(PFH);
    print"$scriptname already running: pid is $pid";
    exit;
}

open(PFH, '>', $pidfile) or die $!;
print(PFH $$);
close(PFH);

# do the job                                                          
+                                   
sleep 13;

unlink($pidfile);
[download]

When you do two things, there is a gap between them.

You discover that the file does not exist with -e. Then there is a gap. Then you create the file by writing to it. That is a race condition - if another process created the file in that gap, you just overwrote it. Now both of you think you own the file.

(You also treat the disappearance of the file between finding it exists and trying to open it as a fatal error, but that's actually another race condition.)

It's quite a while since I did something like this, but as far as I remember a way that works looks something like:

1. If the file exists, you don't own it, give up.
2. Open the file for append, write your pid followed by a newline, close.
3. Open the file for read; if the open failed, you didn't own the file, give up. (Whoever did own it probably just unlinked it, so optionally you could go back to step one to try again - but probably better not to.)
4. Read the first line; if it is not your pid, you don't own the file, give up.
5. You now own the file. When you're done, unlink the file.