Sounds like locking discipline is not being followed consistently.
lock (or die, or wait and retry -- a blocking lock will do this for you)
open db file (or wait and retry)
manipulate db file (or gracefully handle out-of-space)
close db file (or die - very odd. You opened it didn't you?)
release
Gavin Carr wrote:
The rest of your log seems to be doing the right thing. Here in the
first part, the plugin's clearly recognising this is a new ip
address, but it looks as if the write to the db is failing somehow.
It's not a locking issue - the lock is already held at this point.
So I'm
On 24 Mar 2004, at 11:50, Gavin Carr wrote:
The rest of your log seems to be doing the right thing. Here in the
first part,
the plugin's clearly recognising this is a new ip address, but it
looks as if
the write to the db is failing somehow. It's not a locking issue - the
lock is
already held
On Wed, Mar 24, 2004 at 10:31:21PM +, Matt Sergeant wrote:
FWIW I've had very weird stability issues with db files of all
varieties (even DB_File). Especially under extreme load.
Eeerk - not really the answer I was looking for. :-)
I've had much better success with SQLite.
Yeah, I like
Matt Sergeant wrote:
FWIW I've had very weird stability issues with db files of all
varieties (even DB_File). Especially under extreme load. I've had much
better success with SQLite.
Matt,
You may have hit on it. The server is under heavy load. It's replacement is
in the works, but until
Charlie Brady wrote:
On Mon, 22 Mar 2004, Matt Sergeant wrote:
It probably has to be re-written with locking (though I haven't read
the code for the plugin - does it lock?)
Yes, it does lock. I didn't check that it will always remove the lock.
Behaviour probably depends on which form of the
On Tue, 23 Mar 2004, Sam Laffere wrote:
Charlie Brady wrote:
Yes, [greylisting] does lock. I didn't check that it will always remove the lock.
Behaviour probably depends on which form of the command is run - Sam,
are you using select server, or running under tcpserver?
Tcpserver. I
Thanks to all the hard-workers fighting against the spam problem.
I just had to delete the .dbm database because it seemed to be stuck. I did
not see it growing over about a two hour time frame, even though everything
else in the logs looked normal except for the following.
There was one (that I
On 22 Mar 2004, at 21:26, Sam Laffere wrote:
Thanks to all the hard-workers fighting against the spam problem.
I just had to delete the .dbm database because it seemed to be stuck.
DBM files aren't generally safe in the face of multiple writers.
It probably has to be re-written with locking
On Mon, 22 Mar 2004, Sam Laffere wrote:
It also seems that there are a few legitimate mail servers out there that do
not queue and retry on the DENYSOFT.
That sounds like a definition of legitimate which I'm not familiar with
:-)
A couple of instances of customers having immediate denials
On Mon, 22 Mar 2004, Matt Sergeant wrote:
It probably has to be re-written with locking (though I haven't read
the code for the plugin - does it lock?)
Yes, it does lock. I didn't check that it will always remove the lock.
Behaviour probably depends on which form of the command is run -
11 matches
Mail list logo
