in reply to Re^2: Mechanism for ensuring only one instance of a Perl script can only run?
in thread Mechanism for ensuring only one instance of a Perl script can only run?

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]
  • Comment on Re^3: Mechanism for ensuring only one instance of a Perl script can only run?
  • Download Code

Replies are listed 'Best First'.
Re^4: Mechanism for ensuring only one instance of a Perl script can only run?
by hv (Prior) on Dec 06, 2022 at 05:10 UTC

    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.

[reply]
      5. You now own the file. When you're done, unlink the file.

      Please also delete the file when you crash or are killed, e.g. by SIGKILL.

      Yes, I know that's not possible. That's part of why PID files suck, and that's what a monitoring process like supervise from djb's daemontools or even the stinking systemd fixes. And due to the way Unix systems work, all that the monitoring process needs to do is to wait for SIGCHLD or a new task, e.g. sending a signal to the monitored process. In other words: The monitoring process usually does nothing, it is not in the run queue and perhaps swapped out, so it can't do anything wrong. ;-) The O/S kernel will run the monitoring process when anything needs to be done. This reduces the monitoring process to a few lines of code. supervise.c is less than 300 lines, including full error checking.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]

        Yes, that can in principle cause a problem.

        You can try to mitigate it - if you read the pid and find that it is not your own, you can check if that pid is still a running process, and scream bloody murder if it is not. If it is a running process, in some circumstances you can go further and check if it is a process that could legitimately be locking the pid file, and scream bloody murder if not.

        What you want to do in that situation is always going to depend on your particular context.

        In particular it is going to depend on why you are locking. If you are locking access to a resource because you're going to modify it in a way that leaves it invalid/unstable until you are done, then a failure leaves you problems to resolve other than simply being locked out.

        But over many years, I have found that it is pretty rare that a pid file gets left locked due to a failure. And, just speaking of my own experience, it has been exceedingly rare that a locked pid file actually caused a problem - most commonly, you try to do something and see an error message "can't do that, the pid file is locked". And then you remember that the machine just crashed while you were running a similar command a few minutes ago, so you check for breakage, remove the lock file, and continue with your day.

        Maybe I (got real lucky|had excellent judgement) in using a pid file only in situations where failures tended not to cause major problems. Your particular context will determine what the effect will be - whether it will be immediately visible to a human, how easy it is to check for breakage and fix it.

        But if you can get the basics right, a pid file can be a pretty straightforward mechanism that works well enough to solve a particular problem.

[reply]

        Thank you both, hv and afoken,
        this was very enlightening and it seems there's still a lot to learn for me.

[reply]

In Section Seekers of Perl Wisdom