Travel Travel reports, it is all about food
Montreal: Schwartz's, Le Petit Alep
Albums: Pictures and some notes
ITRANS Song Book Hindi, Urdu, Marathi song lyrics
Online ITRANS Web Interface
BlockHosts block hosts
BlockHosts FAQ
BlockHosts Forum
CD Inserts & Envelopes Web Interface
Nisha Ganatra's Films
Cake: starring Heather Graham
Email: avinash@aczoom.com
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.