Julian Grunnell wrote:
> Hi - hoping someone can answer a question for me regarding qmail,
> qmail-spp & greylisting. If this is not the correct place then ...
> sorry, but thought someone might have seen the same problem.
>
> Anyway, I have a qmail server setup as per lifewithqmail and patched
> with qmail-spp. I setup greylisting using greylisting-spp from
> http://www.unix-ag.uni-kl.de/~conrad/greylisting/README.html
>
> This is working a treat but now and again in the smtpd logfile I get:
>
> "@400000004594f07d2da53fd4 plugins/greylisting-spp: Can't lock
> database file "/var/qmail/greylisting-db": Resource temporarily
> unavailable"
>
> This may well appear once for every 100 lines of logfile, the
> permissions are setup as per documentation and tailing the
> greylisting-db shows it is being written to constantly - this is just
> a flat text file.
>
> Thanks - Julian.
>
Hi,
I'm using the same greylisting plugin for qmail-spp, but I'm using sqlite
storage and it has the same problem. When smtp concurency is going to about
20 I will see
"greylisting-spp: Couldn't write entry: database is locked"
in smtp logs each 10 minutes. I think this error is common for file, bdb and
sqlite storage and it means that greylisting-spp can't handle many
simultaneous connections well. Author wrote in README that implementation of
database is at last in BETA quailty, but it wasn't tested on high traffic
servers. Your experience shows that even file storage is broken.
You can use sqlite storage. It has timeout function (sqlite_busy_timeout in
db-sqlite.c) and you can increase the timeout. Maybe in your case it will
help, but I have already increased it to 40 sec. and the busy error is still
there. Increasing above 60 sec. can result in timeouts on the connecting MTA
or MUA.
Last changes in this soft was in September 2004 so I think this project
died.
To solve this problem another implementation of storage should be done. File
system (directory) storage is a good one, because any number of processess
can write to file system at any time and errors occuring due race conditions
can be ignored. Easier to implement can be real database storage like mysql
or postgre, because schema can be based on sqlite implementation. Mysql and
postgre can handle many connections and simultaneous writings with its
advanced locking and queuing.
So... start coding! Anyone? :)
Regs,
Pawel
> (...)
|