[Mimedefang] Multiplexor and reentrancy

Michael D. Sofka sofkam at rpi.edu
Fri Feb 15 16:39:52 EST 2002


At 04:10 PM 2/15/2002 -0500, David F. Skoll wrote:
>On Fri, 15 Feb 2002, Michael D. Sofka wrote:
>
>> But,
>> be warned, razor is not reentrant.  That means you cannot run it with
>> the multiplexor.
>
>Actually, you can (unless it is _very_ weirdly written.)  The multiplexor
>performs all the magical process-pool-management so that individual
>filters do NOT have to be reentrant or thread-safe.  The only time issues
>arise is for deliberately-shared resources like a database file, in which
>case you must use locking to ensure exclusive access.
>
>Within a given Perl process, the filter will _never_ be interrupted.  Your
>filters do not have to be reentrant.

Hum.  Well, here is what happened.  With the multiplexor and local_tests_only
set to 0 the first message checked by each multiplexed mimedefang.pl worked.
Each subsequent message timed out. This would continue until the maxRequests
was reached, at which point one more message would be processed.

Setting local_tests_only to 1 and mimedefang+SpamAssassin worked fine.
Alas, without razor, DNS, MX tests (which I've found increase the hit rate
for spam considerable).

Running mimedefang without the multiplexor and SpamAssassin works correctly
with local_tests_only set to 0.  It's been running that way for two weeks now,
filtered approx 856 messages in that time.  This is on a vanilla Redhat 7.2 box,
sendmail 8.12.2, mimedefang 2.3, SpamAssassin 1.5, razor 1.19.  (Mail gets
more complicated each week.)

It's possible razor is accessing an external file.  I didn't dig into it
since bringing a new mail machine online has been my highest priority.  (The
SpamAssassin test is just a sideline, and an interesting one at that. :-)  In
a couple of weeks I may dig into SpamAssassin 2.0x and razor in more detail.
I'm curious, however, if anybody else is able to recreate the problem.

BTW, I tried setting maxRequests to 1.  That way I would have had pre-forked
mimedefang.pl processes, even if they had to be re-forked after one run.  That
didn't work either, and, again, time did not permit me to dig into it.  (New machine
goes into production tomorrow night.)

Mike

--
Michael Sofka                          sofkam at rpi.edu
CCT Sr. Systems Programmer  email, webmail, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY.    http://www.rpi.edu/~sofkam/




More information about the MIMEDefang mailing list