You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Daniel Quinlan <qu...@pathname.com> on 2004/02/23 05:19:25 UTC
why ctime for stale lock deletion?
Shouldn't we be using mtime for this?
# check age of lockfile ctime
my $now = ($#stat < 11 ? undef : $stat[10]);
@stat = stat($lock_file);
my $lock_age = ($#stat < 11 ? undef : $stat[10]);
if (!defined($lock_age) || ($now - $lock_age) > LOCK_MAX_AGE) {
# we got a stale lock, break it
dbg("lock: $$ breaking stale $lock_file: age=" .
(defined $lock_age ? $lock_age : "undef") . " now=$now");
unlink ($lock_file) || warn "lock: $$ unlink of lock file $lock_file failed: $!\n";
}
Also, we might want to add a trap such that if a process is killed while
waiting for a stale lock, it will delete it on its way out.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: why ctime for stale lock deletion?
Posted by Theo Van Dinter <fe...@kluge.net>.
On Sun, Feb 22, 2004 at 08:19:25PM -0800, Dan Quinlan wrote:
> Shouldn't we be using mtime for this?
Unless I'm missing something, it shouldn't matter really. The last time
the file changed should be == the last time the inode changed.
--
Randomly Generated Tagline:
tmps_base = tmps_max; /* protect our mortal string */
-- Larry Wall in stab.c from the perl source code