On 2014-05-07 15:35, Per Jessen wrote:
Carlos E. R. wrote:
Some way longer:
spamd: clean message (-2.7/5.0) for cer:1000 in 57.3 seconds, 5630 spamd: clean message (-2.6/5.0) for cer:1000 in 53.2 seconds, 7839 bytes.
(see the size)
or
spamd: identified spam (6.5/5.0) for cer:1000 in 213.1 seconds, 15976538 by
That's a very large spam-mail - quite unusual. 213 seconds to process it could be caused by lots of DNS timeouts.
But it is not spam :-) It was sent by me (and to me), from my android phone. It is a dump of just one WhatsApp chat. Yes, it could be DNS timeouts. I have the vague idea that cpu load was high, but I'm unsure. I would have to force filter it again with spamd - ah, I know how. Send to another local account.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13292 cer2 20 0 390280 296056 2112 R 99,87 3,613 0:20.82 spamd child
So, it is not DNS timeouts, it is really processing load.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13292 cer2 20 0 390280 296056 2112 R 99,85 3,613 2:39.40 spamd child
It finished:
<2.6> 2014-05-07 17:19:23 Telcontar spamd 13292 - - spamd: clean message (4.3/5.0) for cer2:1012 in 172.9 seconds, 15982025 bytes. <2.6> 2014-05-07 17:19:23 Telcontar spamd 13292 - - spamd: result: . 4 - DRUGS_MUSCLE,FREEMAIL_FROM,FUZZY_XPILL,LOTS_OF_MONEY,NORMAL_HTTP_TO_IP,T_FRT_COCK,T_FRT_FUCK1,WEIRD_QUOTING scantime=172.9,size=15982025,user=cer2,uid=1012,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=46429,mid=<alpine.LSU.2.11.1405071712370.5918@Telcontar.valinor>,autolearn=no <2.6> 2014-05-07 17:19:23 Telcontar spamd 13289 - - prefork: child states: BI <2.6> 2014-05-07 17:19:23 Telcontar spamd 13289 - - spamd: handled cleanup of child pid [13292] due to SIGCHLD: exit 0 <2.6> 2014-05-07 17:19:23 Telcontar spamd 13289 - - spamd: server successfully spawned child process, pid 10121 <2.6> 2014-05-07 17:19:23 Telcontar spamd 13289 - - prefork: child states: II <2.6> 2014-05-07 17:19:23 Telcontar postfix 10015 - - 27ED861664: to=<cer2@localhost.valinor>, relay=local, delay=174, delays=0.43/0/0/173, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail) <2.6> 2014-05-07 17:19:23 Telcontar postfix 3805 - - 27ED861664: removed
It went a bit faster than the other time, /just/ 173 seconds. And this time it was thought clean. Go figure. At least the child was instantly respawned, as I had changed the config, just one child per email. And memory size did not go that up - or it was not that precise email, there were several similar posts sent in a batch. Maybe I have to send several, locally, and remove --max-conn-per-child=1 temporarily, to reproduce the problem. Doable. Coffee first. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)