in reply to Process Already Running

A PID-based approach to process exclusion suffers from the possibility of PID re-use. Also, there is usually no atomic way of checking the pid *and* registering it. That doesn't mean the approach can't be used in practice, but there is a small probability of malfunction.

A safe approach can be based on file locking (flock), which is *meant* to guarantee exclusive access. The following code shows how that can be done in a Unix-ish environment. I'm sure there is already a module on CPAN (or two) that does this in a more portable way, but I couldn't find it in a hurry. 

#!/usr/local/bin/perl
use strict; use warnings; $| = 1;

use Fcntl qw( :flock);

my $name = 'ttt'; # process name

my $pid_file = "/var/run/$name.pid";

open my $pid_handle, '+<', $pid_file or die "Can't access '$pid_file':
+ $!";
flock $pid_handle, LOCK_EX | LOCK_NB or die "Process $name is still ac
+tive";

truncate $pid_handle, 0 or die "Truncating '$pid_file' failed: $!";
print $pid_handle "$$\n";

# Normal processing starts here
#
# ...

sleep 10; # for testing

[download]
Update: I forgot to mention that the file /var/run/ttt.pid must be pre-created and given ownership and permissions so that the user that runs the process can write it.

Anno

Replies are listed 'Best First'.
Re^2: Process Already Running
by Photius (Sexton) on Sep 13, 2007 at 21:28 UTC
    Thanks for your suggestion. I must have fallen out of a tree and hit my head (or maybe I'm always this stupid). I just realized that the code in my original post would always return TRUE (script already running) because the script itself is, of course, already in the Linux process list when it checks to see if a script of it's same name is already running. Duh!!

    I'm not yet very familiar with Unix-ish systems and am not familiar with PIDs. In your sample code above, why did you open the pid file with +< (is this read-write but don't create?)? And what is the purpose for writing the Perl Process ID $$ to the file? Please help me understand how that is used?
[reply]
      Heh, I didn't even notice the bug in your proposed scheme.

      In your sample code above, why did you open the pid file with +< (is this read-write but don't create?)?

      First off, I don't want to clobber the file before I've made sure I'm allowed to run. That's why plain write access won't do. Write access is required because many systems (foolishly, imo) forbid an exclusive lock on a file that's only open for reading. So even if I didn't intend to write my PID into the file (which is inessential, see below), simple read access would break in some places.

      And what is the purpose for writing the Perl Process ID $$ to the file? Please help me understand how that is used?

      That is absolutely inessential and not used at all. The locking scheme needs a file, unique to the specific program, that can be exclusively locked by the process. I have chosen a convention that is common in Unix systems, associating a process named ttt with a file /var/run/ttt.pid. As the name implies, it is commonly used to store the PID of the running process, and so I've done the same. The locking mechanism would also work without writing anything to the file, or with any other file for that matter.

      I forgot to mention (but will update) that you would have to pre-create the pid file /var/run/ttt.pid (once), and give it ownership and permissions that allow the process write access. A real program should probably explain that in an error message if the file is not found.

      Anno

[reply]
[d/l]
[select]
        Thanks!! That helps greatly.
[reply]
        Thanks! That really helped my understanding.
[reply]

In Section Seekers of Perl Wisdom