At most 1 running copy

[John Summerfield]

On Saturday 27 November 2004 22:03, Ed Wilts wrote:
> On Sat, Nov 27, 2004 at 09:48:31PM +0800, John Summerfield wrote:
> > On Saturday 27 November 2004 12:49, Ed Wilts wrote:
> > > For the record, this snippet works just fine (a per-user lock).
> > >
> > > use FileHandle;
> > > use Fcntl qw(:DEFAULT :flock);
> > > my $FH = new FileHandle;
> > > sysopen(FH, "ftphandler.lock", O_RDWR | O_CREAT) or die "can't open
> > > ftphandler.lock: $!"; flock(FH, LOCK_EX | LOCK_NB) or exit;
> > > print "running...\n";
> > > [rest of code here]
> > > close (FH);
> > > unlink ("ftphandler.lock");
> >
> > I nominated /var/run for a reason:-)
> > It gets cleaned out on a reboot.
>
> 1.  /var/run is not world writable and I don't think it should be.  In
> addition, I wanted to restrict the execution to once per user (actually
> once per user input config file, but that's a different story), not once
> per system.

I didn't check that, but it's easily overcome. There is stuff in there not 
owned by root.

>
> 2.  What's a reboot?  :-)
It's what happens after you install a new kernel, replace the mobo or your UPS 
runs out of juice.


>
> > Sure locks go, but it's nice to <plonk> the files too.
>
> If ftphandler.lock hangs around because the job failed once, it will be
> deleted the next time it's run successfully.  I could sweep through the
> file system deleting old lock files too although I don't think it's
> worth the effort.  That could be in cron.monthly and it would run far
> more frequently than waiting for a reboot...

I'm not keen on such cleanups unless I'm confident it's safe to do so, and
a) I don't know enough about what you're doing to know that.
b) Even if you know what you're doing:-) someone's likely to reuse your code, 
and if they don't understand what's going on they could have mysterious 
failures.

At reboot, you can safely assume it's okay to remove such transient files. 
_Then_ the question is "Where are they?"

If you want an automated ofccasional cleanup, something in /etc/init.d is 
good. Something _you_ write can be given knowledge of these things.






-- 
Cheers
John