Solución 1:
Primero necesita dos archivos:un ejecutable para enviar el correo y un servicio para iniciar el ejecutable. Para este ejemplo, el ejecutable es solo un script de shell que usa sendmail :
/usr/local/bin/systemd-email:
#!/bin/bash
/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <[email protected]$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
$(systemctl status --full "$2")
ERRMAIL
Cualquiera que sea el ejecutable que use, probablemente debería tomar al menos dos argumentos como lo hace este script de shell:la dirección a enviar y el archivo de unidad para obtener el estado. El .service creamos pasará estos argumentos:
/etc/systemd/system/[email protected]:
[Unit]
Description=status email for %i to user
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email address %i
User=nobody
Group=systemd-journal
Donde usuario es el usuario que recibe el correo electrónico y la dirección es la dirección de correo electrónico de ese usuario. Aunque el destinatario está codificado, el archivo de la unidad sobre el que se informa se pasa como un parámetro de instancia, por lo que este servicio puede enviar correos electrónicos para muchas otras unidades. En este punto, puede iniciar [email protected] para verificar que puede recibir los correos electrónicos.
Luego simplemente edite el servicio para el que desea correos electrónicos y agregue [email protected]%n.service al [Unit] sección. %n pasa el nombre de la unidad a la plantilla.
Fuente:archlinux wiki:systemd timers MAILTO
Solución 2:
La solución propuesta por @gf_ funcionó bien para nuestra situación al ejecutar clickhouse en CentOS7. Clickhouse se bloquea con cierta regularidad, por lo que necesitábamos reiniciarlo automáticamente y recibir una notificación cuando se produjera el reinicio. Si bien parece un poco torpe agregar un segundo servicio a systemd, esto es necesario debido al diseño de systemd.
Dicho esto, esta solución, cuando se combina con el reinicio automático, dejó de funcionar para nosotros cuando implementamos CentOS8. Esto se debe a que systemd v239 enviado en C8 introdujo un cambio en el OnFailure= semántica cuando se combina con una configuración no predeterminada de Restart= (Restart=on-failure en nuestro caso). El nuevo OnFailure= El comportamiento solo activa el servicio de una sola vez si el reinicio falla por completo, no solo después de un bloqueo. Este nuevo comportamiento felizmente reiniciaría el servicio, pero no recibiríamos el correo electrónico como OnFailure= ya no se invocaba.
Tenga en cuenta nuestra expectativa principal:queríamos que systemd reiniciara el proceso Y enviara una notificación por correo electrónico. La actualización v239 hizo que nuestra solución anterior citada por gf_ ya no funcionara. Afortunadamente pudimos hacer que esto funcionara.
Nuestra solución es usar ExecStopPost para invocar el script de notificación por correo electrónico. Esto funciona bien, pero ahora surgió un nuevo problema:se envió una notificación por correo electrónico cuando el servicio Clickhouse se inició normalmente, como en el inicio del servidor. Si bien no es un gran problema, idealmente queríamos recibir notificaciones por correo electrónico solo en choques. Pudimos lograr esto agregando el siguiente código a nuestro script de correo electrónico:
# Don't do anything if the service intentionally stopped successfully.
if [ $SERVICE_RESULT == "success" ]; then
exit
fi
... $SERVICE_RESULT es una variable de entorno suministrada por systemd al proceso de destino de ExecStopPost . Al buscar un success Como resultado, asumimos que esta invocación proviene de un inicio o apagado normal y no hacemos nada. En cualquier otro valor, como signal , la secuencia de comandos continuaría en un envío de correo electrónico. Los posibles valores de esta variable se indican en la documentación.
Gracias a gf_ por la solución inicial. Espero que la gente encuentre útil mi actualización para CentOS8. Algunos enlaces más que me ayudaron:
- https://superuser.com/questions/1360346/how-to-send-an-email-alert-when-a-linux-service-ha-stopped
- https://unix.stackexchange.com/questions/422933/confusing-systemd-behaviour-with-onfailure-and-restart
- https://unix.stackexchange.com/questions/197636/ejecutar-un-comando-arbitrario-cuando-un-servicio-falla