Ayuda OnLine de GULiC
Problemas amavis
Buenos dias amigos
Tengo en produccion una pasarela de correo en produccion (Postfix/amavis) que reparte correos a otras máquinas en donde están alojados los buzones despues de analizarlos.
Estoy teniendo serios problemas en los ultimos días. El amavis se queda tostado, se cuelga… coincidiendo con un aumento en el número de procesos del servidor de políticas policyd. hay un momento en que el sistema no puede abrir más ficheros y se cuelga…
Estos son algunos de los errores que me he encontrado.
A alguien se suena lo que puede estar pasando?
Un saludo y muchas gracias
Sep 12 14:32:27 pclinux5 postfix/qmgr[25382]: 7DAE624302: from=pepe@usxpress.com, size=2774, nrcpt=1 (queue active)
Sep 12 14:32:27 pclinux5 postfix/smtp[25383]: fatal: open active A048925398: Too many open files in system
Sep 12 14:32:27 pclinux5 amavis[25408]: (25284-08) (!!) runcommand: child process [25408]: Can’t open /dev/null: Too many op
en files in system at /usr/sbin/amavisd-new line 2108.
Sep 12 14:32:27 pclinux5 amavis[25284]: (25284-08) (!!) TROUBLE in checkmail: partsdecodeext FAILED: parsing file(1) resul
ts - missing last 1 results at (eval 50) line 154.
Sep 12 14:32:27 pclinux5 amavis[25284]: (25284-08) (!) PRESERVING EVIDENCE in /var/lib/amavis/amavis-20070912T143227-25284
Sep 12 14:32:27 pclinux5 postfix/smtpd[22967]: lost connection after MAIL from unknown[80.81.36.238]
Sep 12 14:32:27 pclinux5 postfix/smtpd[22967]: disconnect from unknown[80.81.36.238]
Sep 12 14:32:27 pclinux5 postfix/qmgr[25382]: 7562824305: from=pepe@usxpress.com, size=2734, nrcpt=1 (queue active)
Sep 12 14:32:27 pclinux5 amavis[25409]: (25282-09) (!!) runcommand: child process [25409]: Can’t open /dev/null: Too many open files in system at /usr/sbin/amavisd-new line 2108.
Sep 12 14:32:27 pclinux5 amavis[25282]: (25282-09) (!!) TROUBLE in checkmail: partsdecodeext FAILED: parsing file(1) resul
ts - missing last 1 results at (eval 50) line 154.
Sep 12 14:32:27 pclinux5 postfix/qmgr[25382]: fatal: open active 75B86242C9: Too many open files in system
Sep 12 14:32:27 pclinux5 amavis[25283]: (25283-07) (!!) TROUBLE in checkmail: mimedecode-1 FAILED: MIME::Parser: can’t open
tmpfile: Invalid argument
- Inicie sesión para enviar comentarios
- 581 lecturas
Sería interesante que
Sería interesante que utilizaras netstat para ver el número de conexiones abierta y ver si son muchas. También puede utilizar lsof para ver el número de ficheros abierto. Por ejemplo con:
Puedes conectar el número de conexiones abiertas al servidor de correo. Y con:
El número de archivos abiertos relacionados con postfix. ¿Son muy grandes esos valores? ¿Cuál parece el problema? ¿Demasiados archivos abiertos o demasiadas conexiones?
Saludos
—
May the Free Software Force be with you…
Procesos policyd
Hola
Lo que observo es que el amavis acaba cayendo cuando hay demasiados ficheros abiertos, que al mismo tiempo coincide con la subida de los procesos del policyd del tipo:
0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13247 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13248 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13249 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13250 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13251 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13258 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13259 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13260 ? S 0:00 spawn -n policy -t unix user=polw
Cuando el número de procesos del policyd-weight llega a un umbral de unos… 200, el sistema ya no deja abrir más ficheros y el amavis es quien lo resiente y cae… entonces se me amontonan los correos en cola y tengo cientos de usuarios llamando jeje
Procesos policyd
Hola
Lo que observo es que el amavis acaba cayendo cuando hay demasiados ficheros abiertos, que al mismo tiempo coincide con la subida de los procesos del policyd del tipo:
0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13247 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13248 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13249 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13250 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13251 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13258 ? S 0:00 spawn -n policy -t unix user=polw argv=/usr/bin/perl /usr/lib/postfix/policyd-weight
13259 ? Ss 0:00 /usr/bin/perl /usr/lib/postfix/policyd-weight
13260 ? S 0:00 spawn -n policy -t unix user=polw
Cuando el número de procesos del policyd-weight llega a un umbral de unos… 200, el sistema ya no deja abrir más ficheros y el amavis es quien lo resiente y cae… entonces se me amontonan los correos en cola y tengo cientos de usuarios llamando jeje
¿Y cuantos ficheros hay
¿Y cuantos ficheros hay abiertos según el lsof?
—
May the Free Software Force be with you…
ficheros abiertos
En estos momentos hay 4584 ficheros abiertos con el usuario postfix
y 9701 en total para el sistema
Una cosa que he hecho es cambiar el DNS primario del sistema, que estaba presentando una cierta latencia (pingendo desde la pasarela de correo hasta el) y he puesto otro de la misma subred que el anterior servidor DNS y contra quien no hay latencias…
Llevo un rato así y el sistema está estable (de momento, pero llevo muy poco tiempo)
Los procesos del policyd-weight han llegado a un tope de 185…han vuelto a bajar un poco.. a subir… etc
La cola del correo se limpia rapidamente, pues hasta que no llega al máximo de ficheros abieros no hay problema.
Quizas sea eso simplemente, ya que el policyd-weight necesita resolucion de nombres para trabajar, pero… no se
Si esto fuera así tal vez sería bueno ponerle un DNS cache a la pasarela de correo…
A ver que pasa…
Un saludo
Sería posible que al no
Sería posible que al no resolver bien el dns policyd-weight no termine lo suficientemente rápido, permitiendo que se vayan acumulando los ficheros abierto. Pero en un sistema linux normal el límite está en 380152 archivos abiertos. A mi me parece que tiene que haber muchos procesos esperando mucho tiempo para acumular semejante cantidad de archivos abiertos.
Pero bueno. Esperaremos y a ver que pasa.
—
May the Free Software Force be with you…
Estabilizado
Bueno…
En principio, parece que el sistema se ha estabilizado con este cambio de DNS…
Si de aqui a mañana no ha dado mas problemas te pondré un post, para decirte que era eso… y para quien lea esto lo tenga en cuenta para el futuro
Un saludo y gracias
pues... va a ser eso...
Pues eso…
Con el cambio de DNS… como la seda. Asi que.. que lo sepa todo el mundo, cuando la cola de correo de un sistema Postfix/policyd-weight/amavis se quede colgado con 80.000 correos en cola, con muchisimo procesos y ficharos abiertos… mirad si el DNS que tiene configurado está funcionando bien.
No es que esa sea la única causa, pero lo que es cierto es que si está mal el DNS (y cuando digo mal no me refiero solamente a que esté caído, sino simplemente con que la boca del swicth en donde esté contectado tenga pérdidas de paquetes), el sistema puede ahogarse… Todo depende también del volumen de correos que entren lógicamente.
En mi caso, en una hora, la cola de correo pasó de 0 a 7.000 correos
Un saludo
Pues si que estaba colapsada
Pues si que estaba colapsada la cosa. Nosotros en el curro tenemos un DNS cache para evitar que los servicios más importantes se resientan-
—
May the Free Software Force be with you…
Si los tenemos...
Si, eso es lo correcto
De hecho tenemos 4 DNS… y los 4 estaban puestos en el resolv.conf, pero lo cierto es que el DNS que fallaba esta el primero en la lista y no hice sino cambiar el orden… y la cosa funcionó… En el fondo sigue siendo un misterio.
Un saludo
Para esos casos creo que hay
Para esos casos creo que hay un paquete que sustituye la librería de resolución de nombres habitual por otra que hace las consultas en paralelo a todos los servidores y se queda con la respuesta del primero que responde.
Pero no me preguntes como se llama porque no me acuerdo.
—
May the Free Software Force be with you…
Uffff
Ufff me ha vuelto a pasar.,..
Y eso que hasta le puse un DNS cache propio…
Ahora si que me deja en treita y tres
No creo pero
No creo que sea, pero siempre puedes comprobar los límites máximos en tu sistema:
http://www.cs.wisc.edu/condor/condorg/linux_scalability.html
—
May the Free Software Force be with you…
…. no se si tiene algo que
…. no se si tiene algo que ver, pero cuando esto sucede y reinicio el postfix (nunca lo reinicio en otras circunstancias…) me encuentro con el mensaje:
Warning: bogus file name incoming/XXXXXX
Mira los limites.....
pclinux5:~# cat /proc/sys/fs/file-max
8192
Mi sistema solo permite 8192 ficheros simultaneos???
Asi no es de extrañar que se ahogue en menos que canta un gallo.
No es eso
Eso pasa con todos los Postfix cuando se paran mientras están creando un archivo en la cola. No es importante pues cuando eso pasa no se pierden correos.
Saludos.
—
May the Free Software Force be with you…
file-max
Le he subido el file-max a 32768
Y estoy vigilándolo a ver que pasa.
La máquina tiene 512Mb RAM y recibe unos 30000 correos al día, asi que a lo mejor van por ahi los tiros.
Otro dato
Los correos se estancan porque, por alguna razón no pueden enviar correos a su relayhost por defecto, entonces empiezan a acumularse correos, hasta que el sistema deja de poder abrir nuevos ficheros.
Podría pensarse que se trata de un problema en el equipo remoto (relayhost), pero al hacer un postsuper -r ALL, otra vez vuelve a escupir los correos sin problemas e incluso una cola de 3000 correos se vacía en cuestión de minutos…
He puesto un cron para que en cada hora ejecute este comando, aparte de subierle el file-max
Un saludo