Re: Envío de correos demorados con Exim4
El 19/09/14 13:48, Mauro Antivero escribió: Estimados, en mi lugar de trabajo tenemos un servidor configurado con Cacti, el cual se encarga de enviar alarmas por e-mail cuando algo sucede (por ejemplo un equipo deja de responder o se supera algún límite de temperatura, tráfico, etc. establecido. El problema que estoy teniendo es que a veces cuando hacemos un mantenimiento y apagamos determinados equipos, claro está, se generan varias alarmas. Estas se multiplican exponencialmente si por algún motivo tenemos que apagar uno de los routers que conecta a este servidor (en donde está el Cacti) al resto de los servidores. Pierde toda la conectividad y entonces genera muchísimas alarmas. Pues bien, está claro que lo que hay que hacer es detener el poller de Cacti para realizar este tipo de tareas, pero fuera de eso me gustaría saber que es lo que pasa que cuando se generan tantos correos estos quedan frenados en la cola de salida del servidor en el cual corre Cacti. Ya consulté con el administrador de correo de la cuenta que tiene que recibir dichos correos y me dice que no hay nada que demore la recepción de los mismos. De hecho tiene configurada una lista blanca para aceptar sin peros la recepción de correos provenientes del servidor en cuestión. Esto ya lo han chequeado varias veces y me dicen que el problema no viene por el lado del servidor que recibe, así que por lo tanto apunto a algo en la configuración de Exim4 que ante tantos correos demore la entrega. Como les decía, tomaré el hábito de detener el poller de Cacti, pero me gustaría entender que es lo que pasa. Cualquier ayuda es bienvenida. Pues probablememte lo que pasa es que exim al no poder entregar los correos (router apagado, etc...) los deja en la cola de correo a la espera de poder enviarlos. La cola de correo en exim se procesa cada X tiempo, típicamente cada 15 minutos durante la primera hora (a partir del inicio de la interrupción de la conectividad), cada hora durante las 16 horas siguientes etc... Lo que debe pasar es que el correo sale cuando se procesa la cola y no inmediatamente al recuperarse la conectividad. Se puede forzar un intento de envío de la cola de correo, para no tener que esperar a que le toque, con # exim4 -qf Un saludo JulHer -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541d5021.5030...@escomposlinux.org
Envío de correos demorados con Exim4
Estimados, en mi lugar de trabajo tenemos un servidor configurado con Cacti, el cual se encarga de enviar alarmas por e-mail cuando algo sucede (por ejemplo un equipo deja de responder o se supera algún límite de temperatura, tráfico, etc. establecido. El problema que estoy teniendo es que a veces cuando hacemos un mantenimiento y apagamos determinados equipos, claro está, se generan varias alarmas. Estas se multiplican exponencialmente si por algún motivo tenemos que apagar uno de los routers que conecta a este servidor (en donde está el Cacti) al resto de los servidores. Pierde toda la conectividad y entonces genera muchísimas alarmas. Pues bien, está claro que lo que hay que hacer es detener el poller de Cacti para realizar este tipo de tareas, pero fuera de eso me gustaría saber que es lo que pasa que cuando se generan tantos correos estos quedan frenados en la cola de salida del servidor en el cual corre Cacti. Ya consulté con el administrador de correo de la cuenta que tiene que recibir dichos correos y me dice que no hay nada que demore la recepción de los mismos. De hecho tiene configurada una lista blanca para aceptar sin peros la recepción de correos provenientes del servidor en cuestión. Esto ya lo han chequeado varias veces y me dicen que el problema no viene por el lado del servidor que recibe, así que por lo tanto apunto a algo en la configuración de Exim4 que ante tantos correos demore la entrega. Como les decía, tomaré el hábito de detener el poller de Cacti, pero me gustaría entender que es lo que pasa. Cualquier ayuda es bienvenida. Saludos y gracias, Mauro. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541c182b.3060...@gmail.com
Re: Envío de correos demorados con Exim4
El Fri, 19 Sep 2014 08:48:59 -0300, Mauro Antivero escribió: Estimados, en mi lugar de trabajo tenemos un servidor configurado con Cacti, el cual se encarga de enviar alarmas por e-mail cuando algo sucede (por ejemplo un equipo deja de responder o se supera algún límite de temperatura, tráfico, etc. establecido. (...) Ya consulté con el administrador de correo de la cuenta que tiene que recibir dichos correos y me dice que no hay nada que demore la recepción de los mismos. De hecho tiene configurada una lista blanca para aceptar sin peros la recepción de correos provenientes del servidor en cuestión. Esto ya lo han chequeado varias veces y me dicen que el problema no viene por el lado del servidor que recibe, así que por lo tanto apunto a algo en la configuración de Exim4 que ante tantos correos demore la entrega. Como les decía, tomaré el hábito de detener el poller de Cacti, pero me gustaría entender que es lo que pasa. Cualquier ayuda es bienvenida. No entiendo bien el problema. Cacti genera avisos (por los motivos que sea) y Exim recibe los mensajes y los procesa. Hasta aquí correcto. Ahora dices que los mensajes quedan encolados y no se mandan a los destinatarios por lo que tendrás que ver primero en qué estado están esos mensajes (supongo que en la cola deferred) y si es así tendrás que analizar los registros de Exim para ver por qué no se pudieron enviar en primera instancia (quizá al apagar algunos equipos para el mantenimiento no se pudo contactar con otro servidor de correo secundario y los mensajes no salieron). En cualquier caso, podrás forzar la entrega con exim -q (Google dixit) para comprobar si el problema persiste. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.09.19.13.32...@gmail.com