On 7/28/2016 6:19 PM, Wietse Venema wrote: > I have uploaded a patch that makes postscreen share test results > between concurrent connections from the same IP address. This patch > requires Postfix 3.1 or later. > > ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/ > -r--r--r-- 1 wietse wietse 14473 Jul 28 18:48 > 20160728-postscreen-3.1-3.2.patch > -r--r--r-- 1 wietse wietse 480 Jul 28 19:06 > 20160728-postscreen-3.1-3.2.patch.gpg1 > -r--r--r-- 1 wietse wietse 220 Jul 28 19:06 > 20160728-postscreen-3.1-3.2.patch.gpg2 > -r--r--r-- 1 wietse wietse 280 Jul 28 19:06 > 20160728-postscreen-3.1-3.2.patch.sig > > Wietse > > 20160728 > > Bugfix (introduced: 20090614): with concurrent connections > from the same client IP address, and after-220 tests enabled, > postscreen could overwrite the cached "all tests completed" > result for one connection that completed the after-220 tests, > with the "some tests not completed" result for a concurrent > connection where the client hung up before completing the > after-220 tests. Files: postscreen_misc.c, postscreen_state.c, > postscreen.h, postscreen_tests.c, postscreen.c, postscreen_smtpd.c, > postscreen_early.c. >
This seems to break the postscreen cache cleanup for me. At the scheduled cleanup time: Jul 29 11:54:04 mgate3 postfix/master[81710]: warning: process /usr/libexec/postfix/postscreen pid 14364 killed by signal 11 Jul 29 11:54:04 mgate3 postfix/master[81710]: warning: /usr/libexec/postfix/postscreen: bad command startup -- throttling and thereafter postscreen won't run unless I nuke the database, but then signal 11 at the next scheduled cleanup. Replacing with the unpatched snapshot restores normal operation with the existing database. mail_version = 3.2-20160612 postscreen_cache_cleanup_interval = 12h postscreen_cache_map = btree:$data_directory/postscreen_cache -- Noel Jones
