in reply to Re^2: Abort if instance already running?
in thread Abort if instance already running?

I think the various "nit-picky details" of using file locking like this may be a good reason to stick with the pid-file idea explained in the initial reply -- assuming of course that the goal is to make sure only one instance of a program is running on the same host where you would be trying to start a new instance.

If for some reason there are different hosts that share a given disk and might try to start instances of this process, but only one host at a time may run the one instance of the process, then you'd have to complicate the pid-file approach somewhat, and file locking might be easier/better overall (assuming it works reasonably well on your shared file system... YMMV).

  • Comment on Re^3: Abort if instance already running?

Replies are listed 'Best First'.
Re^4: Abort if instance already running?
by Marshall (Canon) on Jan 06, 2009 at 03:16 UTC
    With Perl, there is always more than one way to do things! There is always a YMMV aspect!

    In the spirit of trying to be helpful, I wrote some simple code that I tested on my Windows machine. Attached below. I think the poster has a couple of solid ideas to work from and can decide what is best for what is likely a complex situation, of which we've only been given a part. It could also be that sometimes method A is best and sometimes method B is best. Sometimes method C is just fine even though it fails 1 of 100,000 times. The below is just an idea of how to implement one of many suggestions.

    #!/usr/bin/perl - w use strict; # test case on ActivePerl 5.10 under WinXP $|++; #turns off stdout buffering #good for testing but a big performance #penalty use Fcntl qw (:flock); $SIG{INT} = \&release_lock; $SIG{QUIT} = \&release_lock; my $lock_file = "$0.lck"; #this next open will succeed if you have w permission... #even if you you don't have the lock yet or lock file #doesn't exist yet.. open LOCKFILE, ">>$lock_file" || die "Cannot open $lock_file"; my $got_lock =flock(LOCKFILE, LOCK_EX | LOCK_NB); if ($got_lock) { print "lock acquired\n"; foreach (1..10) { print "Locked..doing something..$_ seconds\n"; sleep(1); } } else { print STDERR "could not acquire lock\n"; exit(1); } print "Finished...Normal Exit, releasing lock\n"; close LOCKFILE || die "Cannot close $lock_file"; unlink $lock_file || die "Internal program error"; exit(0); #not needed but this is normal close sub release_lock { print STDERR "Abnormal exit...releasing lock\n"; close LOCKFILE || die "Cannot close $lock_file"; unlink $lock_file || die "Internal program error"; exit(2); }
Re^4: Abort if instance already running?
by rir (Vicar) on Jan 06, 2009 at 21:40 UTC
    Even without multiple hosts, also knowing the lockfile technique is worthwhile as it is more easily adaptable to represent other assets. That a lockfile must be cleaned up is an advantage in that situation. The ephemeral (crash) and expensive (proc-table) nature of a process work against you.

    That the process is both the contender and the symbol of contention hinders splitting out functionality into a separate administrative program.

    Under linux /var/lock is the place for lockfiles.

    Be well,
    rir