[Mimedefang] Mimedefang processes are blocking

Dave Close dave at compata.com
Mon Oct 25 02:35:03 EDT 2004


Eleven days ago, I wrote this note to the list:

>I've been running Mimedefang with Sendmail 8.12 for several months. Most
>of the time, it works great. Although I am running the multiplexor, I
>rarely see more than two mimedefang.pl processes. However, about once per
>week, I find several mimedefang processes in state D, blocking. When this
>happens, the system stops processing mail. The load average climbs from
>its normal 1 or 2 to as high as 27, most of which represents the blocked
>mimedefang processes. However, while the CPU load is under 2%, console
>response time is terrible. I can get a response, but it takes very long.

>Thus far, I haven't found a solution to this short of rebooting. I've
>stopped sendmail, mimedefang, and milter-sender, and killed -9 all the
>hung mimedefang processes. When I do that, the load average drops and
>console response time returns to normal. But when I restart the daemons,
>the problem returns within a few minutes. Clearly, I haven't found the
>cause of the blockage, and stopping the daemon is not sufficient to
>clear it. Debugging is possible, but painful, while the system is hung,
>so I don't do much of it; I want to restore service ASAP. But with some
>clue as to where to look, I can certainly do so.

>Details: Red Hat Linux 9.0, completely up-to-date with yum. Sendmail
>8.12.11 built from source to include the milter interface. Mimedefang
>2.43. Milter-sender 0.55.

I never saw any response on the list, but I did get a private reply.
That person observed that I was not using a RAM disk for spool storage
and asserted that doing so would solve the problem. I've now been using
a RAM disk for the last ten days. The problem has just returned. Seven
to ten days is about the interval between problems without the RAM disk.

When the problem happens, I see a large number of Mimedefang processes
in "D" state. blocking but uninterruptable. For example,

  # ps ax | grep defang
    479 ?        S      1:09 /usr/local/bin/mimedefang-multiplexor -p 
/var/spool/MIMEDefang/mimedefang-multiplexor.pid -m 2 -x 10 -U defang -b 600 -l -s 
/var/spool/MIMEDefang/mimedefang-multiplexor.sock
    493 ?        S      2:21 /usr/local/bin/mimedefang -P /var/spool/MIMEDefang/mimedefang.pid -m 
/var/spool/MIMEDefang/mimedefang-multiplexor.sock -U defang -r -s -p 
/var/spool/MIMEDefang/mimedefang.sock
  26534 ?        S      0:03 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6158 ?        D      0:02 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6265 ?        D      0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6266 ?        D      0:02 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6326 ?        D      0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6327 ?        D      0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6334 ?        D      0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6446 ?        D      0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6476 ?        D      0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server
   6477 ?        D      0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server

So my question remains: why is Mimedefang blocking and how can I avoid
this situation?
-- 
Dave Close, Compata, Costa Mesa CA  "You can't go to Windows Update
dave at compata.com, +1 714 434 7359    and get a patch for stupidity."
dhclose at alumni.caltech.edu                  -- Kevin Mitnick




More information about the MIMEDefang mailing list