Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

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

by afoken (Chancellor)
on Dec 04, 2022 at 18:42 UTC ( [id://11148552]=note: print w/replies, xml ) Need Help??


in reply to Re: 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?

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

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

Replies are listed 'Best First'.
Re^3: Mechanism for ensuring only one instance of a Perl script can only run?
by rizzo (Curate) on Dec 06, 2022 at 03:34 UTC

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

      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.

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

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2024-03-29 07:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found