lock file sticking?

I'm a recent BlockHosts installer. I've found log entries telling me that BLockHosts couldn't do anything because the lock file was there. When I check, the lock file was 2+ days old. Is this due to extremely heavy attacks that confuse the script? As a temp fix, I have a crontab entry delete the file every few minutes, but would rather have an answer as to why it's happening and find a solution for it.

Any help is appreciated.

date not important

The lock file date is not important - the file is created on first run (if it does not exist).

What does the log entry exactly say?

The way the lock file works is that it uses the calls to system level lockf() on the lock file, and if no lock can be obtained, then the script exits.

The lock file will always exist (but it is in /tmp, so normal cleanup might delete the file, and it will be created again).

Then, each run of blockhosts tries a lockf(F_LOCK) on the file to get an exclusive lock.
On exit it does a unlock - lockf(F_ULOCK)

Fair enough.

I just also kept seeing log entries on various ssh/ftp attacks where blockhosts.py said the lock file was already there or something and, thus, said something about not doing anything. I guess my best be will be to have blockhosts.py run from something like a crontab, rather than xinetd. Or is that going to cause more problems?

no difference between xinetd or crontab invocation, for lock usa

Unfortunately, there is no difference in lockfile behavior whether you run from crontab or xinetd.

There have been no reports of lock file misbehaving, so can't point to any fix yet. Will need all logs to help figure this out, if it happens again (after the lock file has been removed, it should start working correctly, or if it fails again, send the blockhosts.py log lines starting from the time the lock file was deleted to the point it reports errors).

Alternately, you could always force remove the lock file in crontab on a periodic basis, but this should not be necessary.