[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