postfix: Process did not exit cleanly, returned 1 with signal 0

[Glenn Steen]

2008/6/6 Dave Jenkins <davejenx at googlemail.com>:
> 2008/6/6 Glenn Steen <glenn.steen at gmail.com>:
>> 2008/6/5 Dave Jenkins <davejenx at googlemail.com>:
>>> MailScanner & postfix have mostly been running happily for a few
>>> weeks, averaging about 5 msgs/min. But on two occasions we've had
>>> defunct MailScanner processes and the error "postfix: Process did not
>>> exit cleanly, returned 1 with signal 0".
> ...
>>> ...Finally I turned off
>>> scanning (Scan Messages = no) and this allowed the queue to clear.
>>>
>>> I then switched scanning, virus and spamassassin back on (i.e.
>>> restored previous config) and it then ran fine. I'm wondering if it
>>> was a peculiarity of one of the messages that caused MailScanner to
>>> crash.
>>>
>>> The second time it happened, before clearing the queue I took a copy
>>> of /var/spool/MailScanner/incoming; will that help in debugging the
>>> problem? If so, what should I do with it and if not, what should I do
>>> next time it happens?
>> ...
>> Next time it happens, look in the hold queue, the oldest <batch
>> size... usually 30 or so> messages, to see if you have a problem
>> there.
>
> So it's the Incoming Queue Dir, in my case /var/spool/postfix/hold,
> that I should grab a copy of, rather than Incoming Work Dir
> (/var/spool/MailScanner/incoming), is that right?
>
Yep.

>>  If it were non-queue files fouling things up, doing what you
>> did would likely not have cleared things up, so it might not be the
>> usual razor agent log misplaced in the hold directory...
>
> That makes sense to me; I would have thought the fact that disabling
> scanning alowed the queue to be processed successfully and re-enabling
> scanning restored normal function, suggests that MailScanner choked
> during the scanning of a specific message. So I'm guessing the defunct
> MailScanner processes were the cause rather than effect of the postfix
> process exiting uncleanly.

Sort of, yes. Find whatever message is causing the problem, and then
try submitting it with small changes over and over until it works...
Tedious tweak-work:-).

> All files in my copy of /var/spool/MailScanner/incoming were owned by
> postfix:postfix and all files perm 600, subdirectories 700.
>
>> More like some subtle permission thing or subcomponent "borking totally" on a
>> specific mail.
>> Trick is to find what part and what to do with it:-):-)
>
> I think I've found which mail caused the problem. By finding the time
> of the first "postfix: Process did not exit cleanly" in
> /var/log/messages then looking at what happened around that time in
> /var/log/maillog, I've found a message that fits the timing perfectly
> and that seems to be the first in a growing queue of messages that got
> repeatedly but unsuccessfully processed until I set Scan Messages to
> off. I recognise the recipient from my perusing of the logs the first
> time the problem happened. But this time I have the offending
> message's entry from /var/spool/MailScanner/incoming:
>
> -rw------- 1 postfix postfix 1014 Jun  5 15:39 9E379FE019.AC06E.header
>
> 9E379FE019.AC06E:
> total 32
> drwx------  2 postfix postfix  4096 Jun  5 15:39 .
> drwx------ 31 postfix postfix  4096 Jun  5 15:39 ..
> -rw-------  1 postfix postfix  5571 Jun  5 15:39 msg-1101-41.txt
> -rw-------  1 postfix postfix 14362 Jun  5 15:39 msg-1101-42.html
>
> When I view the files with less, I get:
> "9E379FE019.AC06E/msg-1101-41.txt" may be a binary file.  See it anyway?
>
> # file 9E379FE019.AC06E/msg-1101-41.txt
> 9E379FE019.AC06E/msg-1101-41.txt: Microsoft Office Document
>
> The .html file is OK.
So something about the "office doc" is ... problematic. Or with your
TNEF expander, perhaps... Hard to say, since you don't have the
original file to work with. If I were you, I'd just keep an eye on
things until next time, then grab the hold queue and start
experimenting with that.

> Cheers,
>
> Dave

Cheers to you too;-)
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se