Stan Hoeppner wrote:
On 2/9/2013 11:14 AM, Wietse Venema wrote:
Stan Hoeppner:
Feb 8 22:10:51 greer spamd[17319]: spamd: result: . 0 - BAYES_50
scantime=10.6,size=22153,user=nobody,uid=65534,required_score=4.2,rhost=localhost,raddr=127.0.0.1,rport=44140,mid=<5115cc02.2010...@hardwarefreak.com>,bayes=0.500000,autolearn=disabled
Feb 8 22:14:26 greer postfix/pipe[20325]: A20A86C0A7:
to=<s...@hardwarefreak.com>, relay=spamassassin, delay=226,
delays=0.47/0.02/0/226, dsn=2.0.0, status=sent (delivered via spamassassin service)
The pipe(8) daemon considers the transaction when:
1) spamd terminates.
AND
2) spamd's standard output and standard error are closed.
Normally, 1) implies 2).
In your case, perhaps spamd creates a child process that terminates
four minutes later (as a consequence, it inherits spamd's standard
output and standard error, and closes them four minutes later).
spamd is a long running daemon process, both parent and child. As of
now, last start for both processes was 6:37am CST today, if I'm reading
ps output correctly. The process doesn't terminate after sending output
to the pipe.
So if #1 isn't occurring, then do we assume that spamd is simply
delaying sometimes, for an as yet unknown reason, before closing stdout
and stderr on the pipe connection? Where should I investigate next? As
I mentioned, this delay only occurs for ~dozen of ~1000 msgs. I've not
done a thorough check, but at first glance these do not seem to
correlate to restarts of the daemon.
How are you invoking spamassassin? I've noticed similar behavior in my
setup - amavisd+spamassassin+clamav. Every once in a while a message
seems to take a long time getting through, and I think it's the virus
check that ends up delaying things.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
