Postfix-Amavis-Clamav inestable en SuSE 9.1??
Hola amigos de la lista, me gustaria intercambiar algunas experiencias en la implementacion del Postfix con Amavisd-new y Clamav, todos paquetes incluidos en la distribucion de SuSE Professional 9.1. Veran, anteriormente he podido configurar esta combinacion exitosamente en otras versiones de suse, especialmente con la 9.0, pero a partir de que he cambiado a la version 9.1 encuentro que si bien inicialmente todo funciona bien, al cabo de algunas horas (o dias) las conexiones de los clientes hacia el postfix se quedan en espera (si pruebo un telnet desde el mismo server a localhost al puerto 25 no me responde el banner que normalmente si lo hace) y solo al cabo de 10 o 15 minutos todo se normaliza sin ninguna intervencion por mi parte. Verificando los servicios antes y despues del problema descrito arriba (con netstat -lnt y rcpostfix, rcamavisd, rcclamd status) veo que siguen activos, contrariamente a lo que en un inicio podria preveer de que el postix se pudo haber caido. Verifico en los diferentes logs (mail, messages, localmessages, clamav, etc) y en ningun momento da alguna alerta o mensaje de falla ni para el postfix, amavis o clamav, incluso veo que el amavis prosigue con el escaneo de los correos que estan procesandose y todo esto me lleva a pensar que hay inestabilidad en algunos de estos paquetes, especialmente el postfix o que el amavis satura el sistema. Como les digo esto me ha pasado en la gran mayoria de servidores con suse 9.1 que he tenido la oportunidad de configurar (algo asi de 5 servers desde julio hasta la fecha), quisiera saber si tambien les ha ocurrido casos similares a uds pues esta misma configuracion me ha estado funcionando perfectamente en otras instalaciones pasadas de suse (9.0 para abajo). No creo que sea un tema de saturacion de red o problemas de configuracion de firewall pues se da en diferentes casos de servidores y redes, algunas instalaciones son en pequeñas empresas y otras con mayor cantidad de clientes y ademas en el momento de las interrupciones los otros servicios si logran ser accedidos por los clientes (squid, ldap, apache2, sshd, etc). Les agradecere sus comentarios y de ser necesario puedo publicar los archivos de configuracion usados. Saludos! Marcus
El 2004-08-27 a las 23:55 -0500, Marco Mendoza escribió:
Veran, anteriormente he podido configurar esta combinacion exitosamente en otras versiones de suse, especialmente con la 9.0, pero a partir de que he cambiado a la version 9.1 encuentro que si bien inicialmente todo funciona bien, al cabo de algunas horas (o dias) las conexiones de los clientes hacia el postfix se quedan en espera (si pruebo un telnet desde el mismo server a localhost al puerto 25 no me responde el banner que normalmente si lo hace) y solo al cabo de 10 o 15 minutos todo se normaliza sin ninguna intervencion por mi parte.
Si, lo he observado. Yo tengo postfix, amavis-new, y antivir. Me sucede al recoger el correo con fetchmail, habitualmente al empezar a recoger el de de tiscali, pero no con otros servidores que recojo poco antes en la misma sesión. Tengo dos curas: dejarlo (cuando no me doy cuenta), y suele recperarse en la siguiente vuelta de fetchmail, durante la misma conexión. O bien hago un "rcpostfix restart", que hace cortarse esa descarga atascada, y a la siguiente vuelta continua. Durante el atasco, el postfix ni siquiera atiende peticiones locales, luego no es internet. No hay procesos colgados usando cpu, nada aparente. Suele ocurrir en la primera conexión después de encender el ordenador. Un reporte: Aug 27 00:08:58 nimrodel spamd[7163]: clean message (-4.1/5.0) for cer:500 in 1.1 seconds, 3132 bytes. Aug 27 00:08:58 nimrodel postfix/local[7153]: 684ED29E28: to=<cer@localhost.nimrodel.valinor>, relay=local, delay=1, status=sent (delivered to command: /usr/bin/procmail) Aug 27 00:08:58 nimrodel postfix/qmgr[5262]: 684ED29E28: removed (esa es la última entrada del postfix en el log - funcionando) Aug 27 00:09:13 nimrodel fetchmail[7131]: POP3> STAT Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 143 477635 Aug 27 00:09:15 nimrodel fetchmail[7131]: 143 messages for * at pop.tiscali.es (477635 octets). Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3> LIST 1 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 1 4272 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3> RETR 1 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 4272 bytes Aug 27 00:09:15 nimrodel fetchmail[7131]: reading message *@pop.tiscali.es:1 of 143 (4272 octets) Aug 27 00:09:44 nimrodel ip-up.local.doit: -> FidoNet polled. Aug 27 00:10:26 nimrodel fetchmail[7131]: smtp listener protocol error Aug 27 00:10:31 nimrodel ip-up.local.doit: -> FidoNet tossed and linked Aug 27 00:11:36 nimrodel fetchmail[7131]: smtp listener protocol error Aug 27 00:11:36 nimrodel fetchmail[7131]: SMTP connect to localhost failed Aug 27 00:11:36 nimrodel fetchmail[7131]: POP3> QUIT Aug 27 00:11:36 nimrodel fetchmail[7131]: POP3< jonathan_hughes wrote regarding 'Re: [SLE] iptables driving me mental - New question' on Thu, Aug 26 at 01:46 Aug 27 00:11:36 nimrodel fetchmail[7131]: SMTP transaction error while fetching from pop.tiscali.es Aug 27 00:11:36 nimrodel fetchmail[7131]: 6.2.5 querying pop.tiscali.es (protocol POP3) at Fri Aug 27 00:11:36 2004: poll completed Aug 27 00:11:36 nimrodel fetchmail[7131]: Query status=10 (SMTP) Fijaos que no hay ninguna entrada del postfix en ésta secuencia, ni siquiera se ha enterado (después de más de un minuto de espera). Y estas son las siguientes entradas del postfix - un poco después, tras que el fetchmail ve que no hay correo en otros dos servidores: Aug 27 00:11:45 nimrodel fetchmail[7131]: 6.2.5 querying pop3.terra.es (protocol POP3) at Fri Aug 27 00:11:45 2004: poll completed Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP> QUIT Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP< 221 Bye Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP> QUIT Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: connect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: lost connection after CONNECT from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP< 221 Bye Aug 27 00:11:45 nimrodel fetchmail[7131]: normal termination, status 0 Aug 27 00:11:45 nimrodel postfix/smtpd[7158]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: connect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: lost connection after CONNECT from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1] (esas desconexiones no se a que corresponden) Y, poco después, descarga el mismo correo atascado en la siguiente vuelta del fetchmail, sin quejarse: Aug 27 00:12:38 nimrodel fetchmail[7264]: 144 messages for * at pop.tiscali.es (480189 octets). Aug 27 00:12:38 nimrodel fetchmail[7264]: POP3> LIST 1 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3< +OK 1 4272 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3> RETR 1 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3< +OK 4272 bytes Aug 27 00:12:39 nimrodel fetchmail[7264]: reading message *@pop.tiscali.es:1 of 144 (4272 octets) Aug 27 00:12:40 nimrodel postfix/smtpd[7158]: connect from localhost[127.0.0.1] Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 220 nimrodel.valinor ESMTP Postfix Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> EHLO localhost Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-nimrodel.valinor Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-PIPELINING Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-SIZE 10240000 Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-VRFY Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-ETRN Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 8BITMIME Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> MAIL FROM:<suse-linux-e-return-*@suse.com> SIZE=4272 Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> RCPT TO:<cer@localhost> Aug 27 00:12:40 nimrodel postfix/smtpd[7158]: 6219629E27: client=localhost[127.0.0.1] Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> DATA Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 354 End data with <CR><LF>.<CR><LF> Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP>. (EOM) Aug 27 00:12:40 nimrodel postfix/cleanup[7276]: 6219629E27: message-id=<*@newwww.internal.teleologic.net> Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok: queued as 6219629E27 Aug 27 00:12:40 nimrodel fetchmail[7264]: flushed Aug 27 00:12:40 nimrodel fetchmail[7264]: POP3> DELE 1 Ahora, para comparar, observad una secuencia normal de descarga que si funciona - se ve como el postfix establece una conexión con el postfix enseguida: Aug 20 21:04:32 nimrodel fetchmail[7151]: POP3> RETR 1 Aug 20 21:04:32 nimrodel fetchmail[7151]: POP3< +OK 20472 bytes Aug 20 21:04:32 nimrodel fetchmail[7151]: reading message *@pop.tiscali.es:1 of 106 (20472 octets) Aug 20 21:04:33 nimrodel postfix/smtpd[7211]: connect from localhost[127.0.0.1] Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 220 nimrodel.valinor ESMTP Postfix Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> EHLO localhost Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-nimrodel.valinor Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-PIPELINING Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-SIZE 10240000 Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-VRFY Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-ETRN Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 8BITMIME Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> MAIL FROM:<*@yahoo.com> SIZE=20472 Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 Ok Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> RCPT TO:<cer@localhost> Aug 20 21:04:33 nimrodel postfix/smtpd[7211]: 1964729E24: client=localhost[127.0.0.1] Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 Ok Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> DATA Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 354 End data with <CR><LF>.<CR><LF> Aug 20 21:04:35 nimrodel postfix/cleanup[7174]: 1964729E24: message-id=<410739ED002077CD@pop4.es.tisadm.net> (added by postmaster@netmail.tiscali.es) Aug 20 21:05:05 nimrodel fetchmail[7151]: SMTP>. (EOM) Aug 20 21:05:05 nimrodel fetchmail[7151]: SMTP< 250 Ok: queued as 1964729E24 Aug 20 21:05:05 nimrodel fetchmail[7151]: flushed Aug 20 21:05:05 nimrodel fetchmail[7151]: POP3> DELE 1 (por cierto, era spam) Aug 20 21:05:05 nimrodel amavis[4531]: (04531-02) warning - MIME::Parser error: part did not end with expected boundary; error: unexpected end of parts before epilogue
Verificando los servicios antes y despues del problema descrito arriba (con netstat -lnt y rcpostfix, rcamavisd, rcclamd status) veo que siguen activos, contrariamente a lo que en un inicio podria preveer de que el postix se pudo haber caido.
No, no se ha caido nada, porque un par de minutos después se ve en mi secuencia que continúa tal cual. Lo que si es cierto es que el postfix se queda alelado.
Como les digo esto me ha pasado en la gran mayoria de servidores con suse 9.1 que he tenido la oportunidad de configurar (algo asi de 5 servers desde julio hasta la fecha), quisiera saber si tambien les ha ocurrido casos similares a uds pues esta misma configuracion me ha estado funcionando perfectamente en otras instalaciones pasadas de suse (9.0 para abajo). No creo que sea un tema de saturacion de red o problemas de configuracion de firewall pues se da en diferentes casos de servidores y redes, algunas instalaciones son en pequeñas empresas y otras con mayor cantidad de clientes y ademas en el momento de las interrupciones los otros servicios si logran ser accedidos por los clientes (squid, ldap, apache2, sshd, etc).
Yo estoy empezando a pensar que el sistema de red de la 9.1 pierde paquetes :-? O eso, o el postfix este tiene un bug. Podríamos probar con la versión nueva, si existe, en people/choeger
Les agradecere sus comentarios y de ser necesario puedo publicar los archivos de configuracion usados.
No creo que afecte, es heredado del 8.2 -- Saludos Carlos Robinson
Gracias por los comentarios Carlos!!! me han sido de mucha utilidad para analizar la posible causa a este problema, ahora tengo una teoria, a ver q opinas de ella .... En primer lugar si me comentas que usas el antivir en lugar del clamav (eso sumado a que tambien me sucede lo mismo con el uvscan de mcafee) entonces definitivamente descarta que sea el paquete antivirus el posible causante del problema. Lo que se muestra en tus logs es similar a lo que ocurre en mi caso : por unos minutos las lineas del postfix/smtpd desaparecen y solo aparecen mensajes de los otros servicios incluidos en el /var/log/mail que en mi caso son el imapd, ipop3d y lo mas importante .... del amavis!! veo que el amavis sigue procesando sus filtros en los mails. Esto ultimo en el comportamiento del amavis me lleva a pensar que quizas es este paquete el cuello de botella, procesa una cantidad limitada de pre-forks, en mi caso la tengo configurada en un maximo de 4 (por defecto SuSE la deja en 2) en el /etc/amavisd.conf : $max_servers = 4; # number of pre-forked children (default 2) y por supuesto esto implica tener una linea en el /etc/postfix/master.cf de la siguiente manera : smtp-amavis unix - - n - 4 smtp O sea que el amavis puede manejar un maximo de 4 procesos de filtrado a la vez (sea de mails q entran o salen del server), y q pasa al 5to o 6to mail que esta tratando de entrar al servidor??? esto significara que el amavis se bloquea llevandose consigo al postfix??? esto sera el motivo del efecto de que el puerto 25 smtp se "bloquee"??? es entonces el valor de "max_servers = 4" muy conservador??? pero aun asi, en mis instalaciones anteriores con SuSE 9.0 para abajo con estas mismas cantidades en el pre-fork del amavis nunca tuve problemas, solo ocurre con esta nueva version 9.1 (incluso algunas funcionaban tranquilamente con el valor por defecto de 2), estuve chequeand algo de eso en la web y encontre una configuracion con un valor de 75 http://perlstalker.amigo.net/courier/scripts/amavisd.conf.diff-20040701), q me parece exagerada, q opinas??? Como tienes configurado tu el valor de "max_servers" ??? sera ese el problema??? q opinas de mi teoria? explicaria tambien tus dificultades?? espero tus comentarios....... La otra manera de descartar creo que no seria otra mas que bajarme los tarballs de estos paquetes y empezar a compilar....... Saludos Marcus ----- Original Message ----- From: "Carlos E. R." <robin1.listas@tiscali.es> To: "Lista de Suse Linux Español" <suse-linux-s@suse.com> Sent: Saturday, August 28, 2004 5:35 PM Subject: Re: [suse-linux-s] Postfix-Amavis-Clamav inestable en SuSE 9.1??
El 2004-08-27 a las 23:55 -0500, Marco Mendoza escribió:
Veran, anteriormente he podido configurar esta combinacion exitosamente
otras versiones de suse, especialmente con la 9.0, pero a partir de que he cambiado a la version 9.1 encuentro que si bien inicialmente todo funciona bien, al cabo de algunas horas (o dias) las conexiones de los clientes hacia el postfix se quedan en espera (si pruebo un telnet desde el mismo server a localhost al puerto 25 no me responde el banner que normalmente si lo hace) y solo al cabo de 10 o 15 minutos todo se normaliza sin ninguna intervencion por mi parte.
Si, lo he observado.
Yo tengo postfix, amavis-new, y antivir. Me sucede al recoger el correo con fetchmail, habitualmente al empezar a recoger el de de tiscali, pero no con otros servidores que recojo poco antes en la misma sesión. Tengo dos curas: dejarlo (cuando no me doy cuenta), y suele recperarse en la siguiente vuelta de fetchmail, durante la misma conexión. O bien hago un "rcpostfix restart", que hace cortarse esa descarga atascada, y a la siguiente vuelta continua. Durante el atasco, el postfix ni siquiera atiende peticiones locales, luego no es internet. No hay procesos colgados usando cpu, nada aparente. Suele ocurrir en la primera conexión después de encender el ordenador.
Un reporte:
Aug 27 00:08:58 nimrodel spamd[7163]: clean message (-4.1/5.0) for cer:500 in 1.1 seconds, 3132 bytes. Aug 27 00:08:58 nimrodel postfix/local[7153]: 684ED29E28: to=<cer@localhost.nimrodel.valinor>, relay=local, delay=1, status=sent (delivered to command: /usr/bin/procmail) Aug 27 00:08:58 nimrodel postfix/qmgr[5262]: 684ED29E28: removed
(esa es la última entrada del postfix en el log - funcionando)
Aug 27 00:09:13 nimrodel fetchmail[7131]: POP3> STAT Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 143 477635 Aug 27 00:09:15 nimrodel fetchmail[7131]: 143 messages for * at
Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3> LIST 1 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 1 4272 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3> RETR 1 Aug 27 00:09:15 nimrodel fetchmail[7131]: POP3< +OK 4272 bytes Aug 27 00:09:15 nimrodel fetchmail[7131]: reading message *@pop.tiscali.es:1 of 143 (4272 octets) Aug 27 00:09:44 nimrodel ip-up.local.doit: -> FidoNet polled. Aug 27 00:10:26 nimrodel fetchmail[7131]: smtp listener protocol error Aug 27 00:10:31 nimrodel ip-up.local.doit: -> FidoNet tossed and linked Aug 27 00:11:36 nimrodel fetchmail[7131]: smtp listener protocol error Aug 27 00:11:36 nimrodel fetchmail[7131]: SMTP connect to localhost failed Aug 27 00:11:36 nimrodel fetchmail[7131]: POP3> QUIT Aug 27 00:11:36 nimrodel fetchmail[7131]: POP3< jonathan_hughes wrote regarding 'Re: [SLE] iptables driving me mental - New question' on Thu, Aug 26 at 01:46 Aug 27 00:11:36 nimrodel fetchmail[7131]: SMTP transaction error while fetching from pop.tiscali.es Aug 27 00:11:36 nimrodel fetchmail[7131]: 6.2.5 querying pop.tiscali.es (protocol POP3) at Fri Aug 27 00:11:36 2004: poll completed Aug 27 00:11:36 nimrodel fetchmail[7131]: Query status=10 (SMTP)
Fijaos que no hay ninguna entrada del postfix en ésta secuencia, ni siquiera se ha enterado (después de más de un minuto de espera). Y estas son las siguientes entradas del postfix - un poco después, tras que el fetchmail ve que no hay correo en otros dos servidores:
Aug 27 00:11:45 nimrodel fetchmail[7131]: 6.2.5 querying pop3.terra.es (protocol POP3) at Fri Aug 27 00:11:45 2004: poll completed Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP> QUIT Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP< 221 Bye Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP> QUIT Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: connect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: lost connection after CONNECT from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel fetchmail[7131]: SMTP< 221 Bye Aug 27 00:11:45 nimrodel fetchmail[7131]: normal termination, status 0 Aug 27 00:11:45 nimrodel postfix/smtpd[7158]: disconnect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: connect from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: lost connection after CONNECT from localhost[127.0.0.1] Aug 27 00:11:45 nimrodel postfix/smtpd[7146]: disconnect from localhost[127.0.0.1]
(esas desconexiones no se a que corresponden)
Y, poco después, descarga el mismo correo atascado en la siguiente vuelta del fetchmail, sin quejarse:
Aug 27 00:12:38 nimrodel fetchmail[7264]: 144 messages for * at
Aug 27 00:12:38 nimrodel fetchmail[7264]: POP3> LIST 1 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3< +OK 1 4272 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3> RETR 1 Aug 27 00:12:39 nimrodel fetchmail[7264]: POP3< +OK 4272 bytes Aug 27 00:12:39 nimrodel fetchmail[7264]: reading message *@pop.tiscali.es:1 of 144 (4272 octets) Aug 27 00:12:40 nimrodel postfix/smtpd[7158]: connect from localhost[127.0.0.1] Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 220 nimrodel.valinor ESMTP Postfix Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> EHLO localhost Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-nimrodel.valinor Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-PIPELINING Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-SIZE 10240000 Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-VRFY Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250-ETRN Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 8BITMIME Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> MAIL FROM:<suse-linux-e-return-*@suse.com> SIZE=4272 Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> RCPT TO:<cer@localhost> Aug 27 00:12:40 nimrodel postfix/smtpd[7158]: 6219629E27: client=localhost[127.0.0.1] Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP> DATA Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 354 End data with <CR><LF>.<CR><LF> Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP>. (EOM) Aug 27 00:12:40 nimrodel postfix/cleanup[7276]: 6219629E27: message-id=<*@newwww.internal.teleologic.net> Aug 27 00:12:40 nimrodel fetchmail[7264]: SMTP< 250 Ok: queued as 6219629E27 Aug 27 00:12:40 nimrodel fetchmail[7264]: flushed Aug 27 00:12:40 nimrodel fetchmail[7264]: POP3> DELE 1
Ahora, para comparar, observad una secuencia normal de descarga que si funciona - se ve como el postfix establece una conexión con el postfix enseguida:
Aug 20 21:04:32 nimrodel fetchmail[7151]: POP3> RETR 1 Aug 20 21:04:32 nimrodel fetchmail[7151]: POP3< +OK 20472 bytes Aug 20 21:04:32 nimrodel fetchmail[7151]: reading message *@pop.tiscali.es:1 of 106 (20472 octets) Aug 20 21:04:33 nimrodel postfix/smtpd[7211]: connect from localhost[127.0.0.1] Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 220 nimrodel.valinor ESMTP Postfix Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> EHLO localhost Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-nimrodel.valinor Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-PIPELINING Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-SIZE 10240000 Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-VRFY Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250-ETRN Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 8BITMIME Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> MAIL FROM:<*@yahoo.com> SIZE=20472 Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 Ok Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> RCPT TO:<cer@localhost> Aug 20 21:04:33 nimrodel postfix/smtpd[7211]: 1964729E24: client=localhost[127.0.0.1] Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 250 Ok Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP> DATA Aug 20 21:04:33 nimrodel fetchmail[7151]: SMTP< 354 End data with <CR><LF>.<CR><LF> Aug 20 21:04:35 nimrodel postfix/cleanup[7174]: 1964729E24: message-id=<410739ED002077CD@pop4.es.tisadm.net> (added by
Aug 20 21:05:05 nimrodel fetchmail[7151]: SMTP>. (EOM) Aug 20 21:05:05 nimrodel fetchmail[7151]: SMTP< 250 Ok: queued as 1964729E24 Aug 20 21:05:05 nimrodel fetchmail[7151]: flushed Aug 20 21:05:05 nimrodel fetchmail[7151]: POP3> DELE 1
(por cierto, era spam)
Aug 20 21:05:05 nimrodel amavis[4531]: (04531-02) warning - MIME::Parser error: part did not end with expected boundary; error: unexpected end of
en pop.tiscali.es (477635 octets). pop.tiscali.es (480189 octets). postmaster@netmail.tiscali.es) parts before epilogue
Verificando los servicios antes y despues del problema descrito arriba
netstat -lnt y rcpostfix, rcamavisd, rcclamd status) veo que siguen activos, contrariamente a lo que en un inicio podria preveer de que el postix se
(con pudo
haber caido.
No, no se ha caido nada, porque un par de minutos después se ve en mi secuencia que continúa tal cual. Lo que si es cierto es que el postfix se queda alelado.
Como les digo esto me ha pasado en la gran mayoria de servidores con suse 9.1 que he tenido la oportunidad de configurar (algo asi de 5 servers desde julio hasta la fecha), quisiera saber si tambien les ha ocurrido casos similares a uds pues esta misma configuracion me ha estado funcionando perfectamente en otras instalaciones pasadas de suse (9.0 para abajo). No creo que sea un tema de saturacion de red o problemas de configuracion de firewall pues se da en diferentes casos de servidores y redes, algunas instalaciones son en pequeñas empresas y otras con mayor cantidad de clientes y ademas en el momento de las interrupciones los otros servicios si logran ser accedidos por los clientes (squid, ldap, apache2, sshd, etc).
Yo estoy empezando a pensar que el sistema de red de la 9.1 pierde paquetes :-?
O eso, o el postfix este tiene un bug. Podríamos probar con la versión nueva, si existe, en people/choeger
Les agradecere sus comentarios y de ser necesario puedo publicar los archivos de configuracion usados.
No creo que afecte, es heredado del 8.2
-- Saludos Carlos Robinson
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 2004-08-29 a las 00:38 -0500, Marco Mendoza escribió: ...
Esto ultimo en el comportamiento del amavis me lleva a pensar que quizas es este paquete el cuello de botella, procesa una cantidad limitada de pre-forks, en mi caso la tengo configurada en un maximo de 4 (por defecto SuSE la deja en 2) en el /etc/amavisd.conf :
$max_servers = 4; # number of pre-forked children (default 2)
y por supuesto esto implica tener una linea en el /etc/postfix/master.cf de la siguiente manera :
smtp-amavis unix - - n - 4 smtp
No, no es es el problema. Por dos motivos. Uno, que en mi caso todavía no está procesando correos, acaba de conectarse. Dos, que es el postfix quien le envia correos al amavis. Si se topa con el límite de procesos, es el postfix quien deja de enviarle trabajo, y se lo guarda en sus colas temporales (más bien, no lo saca de la cola donde ya está guardado) hasta que tenga un 'smtp-amavis' libre donde enviarlo. Eso no supone más carga para el sistema, sino al contrario. Lo se, lo he comprobado: en una maquina lenta, un P-120, si no limito el numero de hijos, el sistema se me colapsa. Llego a tener un centenar de procesos amavis y spamc, que son procesos perl con mucha memoria, cuando ese ordenador tiene solo 32 megas, con lo que swapea procesos. Llega a tardar media hora por correo procesado, a temporizar, y a rebotarlos hacia atrás. Si limito a un unico proceso, el tiempo es de 15 segundos y funciona: lento pero seguro. Y, en realidad, más rápido.
Como tienes configurado tu el valor de "max_servers" ??? sera ese el problema??? q opinas de mi teoria? explicaria tambien tus dificultades?? espero tus comentarios.......
Creo que es esto: vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender} ${recipient} O sea, 10, si no me equivoco de columna. En mi maquina pequeña creo que lo tengo a 2 o incluso a 1, no recuerdo ahora mismo. En el amavis: # Net::Server pre-forking settings # You may want $max_servers to match the width of your MTA pipe # feeding amavisd, e.g. with Postfix the 'Max procs' field in the # master.cf file, like the '2' in the: smtp-amavis unix - - n - 2 smtp # $max_servers = 2; # number of pre-forked children (default 2) $max_requests = 10; # retire a child after that many accepts (default 10) Ah, ojo: max_servers es el numero de hijos que tiene arrancados en espera. No estoy seguro que sea el maximo (absoluto) numero de hijos. Pfssss! El amavis-new me desespera, no tiene manuales :-/ Pero estoy viendo que está a dos, y el postfix está a 10. Tendría que cambiar uno de los dos. Tengo que revisar mi 'master.cf', lo veo raro.
La otra manera de descartar creo que no seria otra mas que bajarme los tarballs de estos paquetes y empezar a compilar.......
No hace falta, el postfix hay uno en SuSE que los prepara, lo dije ayer. P.D: Deberías haber recortado mi mensaje, son 11 kilobytes extra para enviar a todos los subscriptores. -- Saludos Carlos Robinson
participants (2)
-
Carlos E. R. -
Marco Mendoza