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. Thanks Wietse, -- Stan
