Snapshot 20091209 postscreen failure
in [Postfix]
|
From: "Len Conrad" on 17 Dec 2009 13:30 >Len Conrad: >> Dec 17 11:28:39 mx1 postfix/postscreen[4867]: fatal: open database /var/db/postfix/ps_cache.db: Invalid argument >> > >You switched Berkeley DB versions, or you switched >btree/hash types. maybe "portsnap fetch update" upped the BDB version, I've changed nothing in the main.cf file. > >Delete the file, and try again. When I saw found the error in syslog, I cp /dev/null to the file, but it still failed. rm the file works thanks Len
From: "Len Conrad" on 17 Dec 2009 17:33 ---------- Original Message ---------------------------------- From: "Len Conrad" <lconrad(a)Go2France.com> Reply-To: <lconrad(a)Go2France.com> Date: Thu, 17 Dec 2009 19:30:54 +0100 > >>Len Conrad: >>> Dec 17 11:28:39 mx1 postfix/postscreen[4867]: fatal: open database /var/db/postfix/ps_cache.db: Invalid argument >>> >> >>You switched Berkeley DB versions, or you switched >>btree/hash types. > >maybe "portsnap fetch update" upped the BDB version, I've changed nothing in the main.cf file. > > >> >>Delete the file, and try again. > >When I saw found the error in syslog, I cp /dev/null to the file, but it still failed. rm the file works ========== Is it possible/acceptable that ps_cache.db be a mysql table? Len
From: Wietse Venema on 17 Dec 2009 17:50
Len Conrad: > >>Len Conrad: > >>> Dec 17 11:28:39 mx1 postfix/postscreen[4867]: fatal: open database /var/db/postfix/ps_cache.db: Invalid argument > >>> > >> > >>You switched Berkeley DB versions, or you switched > >>btree/hash types. > > > >maybe "portsnap fetch update" upped the BDB version, I've changed nothing in the main.cf file. > > > > > >> > >>Delete the file, and try again. > > > >When I saw found the error in syslog, I cp /dev/null to the file, > > but it still failed. rm the file works Berkeley DB does not handle truncation gracefully. > Is it possible/acceptable that ps_cache.db be a mysql table? To discourage you from doing such things, postscreen now logs an alert every time that database access takes 100ms or more. When this alert triggers, postscreen performance is reduced to less than 10 SMTP connections per second. That's worse than not running postscreen at all. Wietse |