Mailinglist Archive: opensuse-es (1722 mails)
| < Previous | Next > |
Re: [suse-linux-s] Postfix-Amavis-Clamav inestable en SuSE 9.1??
- From: "Marco Mendoza" <marcomendoza@xxxxxxx>
- Date: Sun, 29 Aug 2004 00:38:38 -0500
- Message-id: <002201c48d8a$70bdb2a0$0d01a8c0@menmar>
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@xxxxxxxxxx>
To: "Lista de Suse Linux Español" <suse-linux-s@xxxxxxxx>
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
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@xxxxxxxxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxxxxx> (added by
postmaster@xxxxxxxxxxxxxxxxxx)
> 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
>
>
> --
> Para dar de baja la suscripción, mande un mensaje a:
> suse-linux-s-unsubscribe@xxxxxxxx
> Para obtener el resto de direcciones-comando, mande
> un mensaje a:
> suse-linux-s-help@xxxxxxxx
>
>
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@xxxxxxxxxx>
To: "Lista de Suse Linux Español" <suse-linux-s@xxxxxxxx>
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
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@xxxxxxxxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxxxxx> (added by
postmaster@xxxxxxxxxxxxxxxxxx)
> 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
>
>
> --
> Para dar de baja la suscripción, mande un mensaje a:
> suse-linux-s-unsubscribe@xxxxxxxx
> Para obtener el resto de direcciones-comando, mande
> un mensaje a:
> suse-linux-s-help@xxxxxxxx
>
>
| < Previous | Next > |