[Mimedefang] Undelivered messages
Roberto Machado
racm at centroin.com.br
Fri Mar 1 17:46:18 EST 2002
On Wed, 27 Feb 2002, David F. Skoll wrote:
> Also, if you manage to duplicate it, could you use strace (linux) or
> truss (Solaris) to see what the mimedefang process is doing? e.g:
>
> strace -p pid_of_mimedefang_process > TRACE.OUT 2>&1
Here follows the ktrace output. When I noticed the mimedefang process
consuming all cpu, I started the ktrace and there were a lot of lines
like:
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
[...]
In a few seconds the file grew to 100MB. I did another run, in order
to capture the moment where this loop ends. This is what I got:
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang GIO fd 7 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x7,0x4815ceac,0)
306 mimedefang RET write -1 errno 32 Broken pipe
306 mimedefang CALL read(0x8,0x4815c6ac,0x1000)
306 mimedefang GIO fd 8 read 4096 bytes
"QUFid0JwQUc0QWRBQWdBRVFBYndCakFIVUFiUUJsQUc0QWRBQUFB
QUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNnQUFnRUNBQUFB
[ ... more bytes ...]
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFLQUFDQVFRQUFBRC8vLy8v
306 mimedefang RET write -1 errno 32 Broken pipe
306 mimedefang CALL read(0x8,0x4815c6ac,0x1000)
306 mimedefang GIO fd 8 read 4096 bytes
[...]
Naturally, I tried to run one more time, in order to capture what
happened before the condition occured:
306 mimedefang RET read 4096/0x1000
306 mimedefang CALL select(0x9,0,0x4816b3fc,0,0x4816b35c)
306 mimedefang RET select 1
306 mimedefang CALL write(0x8,0x4816b594,0x5)
306 mimedefang GIO fd 8 wrote 5 bytes
"\0\0\^P\^Ab"
306 mimedefang RET write 5
306 mimedefang CALL select(0x9,0,0x4816b3fc,0,0x4816b35c)
306 mimedefang RET select 1
306 mimedefang CALL write(0x8,0x4816d6ac,0x1000)
306 mimedefang GIO fd 8 wrote 2048 bytes
"
bWFfcGFyYV9yZXNvbHU9RTc9RTNvX2RlX3Byb2JsZW1hcyEhISE/PQ0KRGF0
[... suppressed ...]
b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQNCg0KME04UjRLR3hH
dUVBQUFBQUFBQUFBQUFBQUFBQUFBQUFQZ0FEQVA3L0NRQUdBQUFBQUFBQUFB
QUFBQUFDQUFBQW5RQUFBQUFBQUFBQQ0KRU"
306 mimedefang RET write 2048/0x800
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang RET write 5
306 mimedefang CALL select(0x9,0,0x4816b3fc,0,0x4816b35c)
306 mimedefang RET select 1
306 mimedefang CALL write(0x8,0x4816d6ac,0x1000)
306 mimedefang GIO fd 8 wrote 2048 bytes
"
bWFfcGFyYV9yZXNvbHU9RTc9RTNvX2RlX3Byb2JsZW1hcyEhISE/PQ0KRGF0
[... suppressed ...]
b2JpbWJvLmNvbT4NClN1YmplY3Q6ID0/aXNvLTg4NTktMT9RP2ZsdXhvZ3Jh"
306 mimedefang RET write 4096/0x1000
306 mimedefang CALL read(0x9,0x4816d6ac,0x1000)
306 mimedefang GIO fd 9 read 4096 bytes
"
bWFfcGFyYV9yZXNvbHU9RTc9RTNvX2RlX3Byb2JsZW1hcyEhISE/PQ0KRGF0
[... suppressed ...]
QUFBQUFBQUFBRGZaeWFxV01BQg0KY0FBQUFJQUNBQUFBQUFBQVVBQnZBSGNB
WlFCeUFG"
306 mimedefang RET read 4096/0x1000
306 mimedefang CALL select(0x9,0,0x4816b3fc,0,0x4816b35c)
306 mimedefang RET select 1
306 mimedefang CALL write(0x8,0x4816b594,0x5)
306 mimedefang GIO fd 8 wrote 5 bytes
"\0\0\^P\^Ab"
306 mimedefang RET write 5
306 mimedefang CALL select(0x9,0,0x4816b3fc,0,0x4816b35c)
306 mimedefang RET select 1
306 mimedefang CALL write(0x8,0x4816d6ac,0x1000)
306 mimedefang GIO fd 8 wrote 2048 bytes
"
bWFfcGFyYV9yZXNvbHU9RTc9RTNvX2RlX3Byb2JsZW1hcyEhISE/PQ0KRGF0
[... suppressed ...]
Ow0KCW5hbWU9IkZsdXhvZ3JhbWEucHBzIg0KQ29udGVudC1EaXNwb3NpdGlv
bjogYXR0YWNobWVudDsNCglmaWxlbmFtZT0iRmx1eG9ncmFtYS5wcHMiDQpD
b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQNCg0KME04UjRLR3hH
dUVBQUFBQUFBQUFBQUFBQUFBQUFBQUFQZ0FEQVA3L0NRQUdBQUFBQUFBQUFB
QUFBQUFDQUFBQW5RQUFBQUFBQUFBQQ0KRU"
306 mimedefang RET write 2048/0x800
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
306 mimedefang RET write 0
306 mimedefang CALL write(0x8,0x4816deac,0)
306 mimedefang GIO fd 8 wrote 0 bytes
""
Something that I noticed is that mimedefang.pl seems to run ok. The
problem shows up after it is completed, and when mimedefang gets back
the control. In fact, I compared the last strings in the GIO call,
and found that they are inside the message text, located around 44%
after the begining of the message. Supposedely, mimedefang should
keep feeding the message to the socket, but stops with these null
writes.
Hope this helps you somehow!
Thanks again!
Roberto
More information about the MIMEDefang
mailing list