El advenedizo no vuelve a abrir los archivos de registro en logrotation

Question

Usamos advenedizo para administrar nuestros servicios en nuestros servidores Ubuntu. Producen registros que se desconectan en /var/log/upstart/SERVICE_NAME.log

Luego, diariamente, los archivos de registro se rotan usando el script logrotation que viene con 12.04 LTS:

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

El problema es que mientras logrotate mueve los archivos, no parece indicarle al advenedizo que cierre y vuelva a abrir los archivos, lo que deja al proceso advenedizo escribiendo en un PID de eliminación.

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762 

Obviamente, podría redirigir la salida de mis propios servicios a otros archivos de registro, pero el problema seguiría ahí para los procesos del sistema. Además, preferiría no tener que construir más infraestructura de la que necesito.

Answer 1

Creo que tienes 3 opciones.

1. Modificas la configuración existente agregando "copytruncate"

   /var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }

2. Si no puede o (no está permitido) cambiar la configuración de logrotate existente debido a otros archivos de registro que no sufren y la configuración existente funciona para ellos, mueva sus archivos "SERVICE_NAME.log" a una nueva carpeta en / var/log si lo desea, cree una nueva configuración con "copytruncate" y agréguela al cron.daily.

3. a) Si no tiene permiso para cambiar la configuración de logrotate del sistema operativo host o agregarla al cron.daily del sistema operativo host, entonces su tercera opción es cambiar los scripts o programas para verificar que el archivo existe antes de escribirlo. b) Otra forma es un poco del punto 2 anterior, que consiste en mover sus archivos de registro a otro lugar y dentro de su script o programa, ejecutar el comando logrotate específico para el archivo de registro de ese programa.

El punto 3b anterior es más complicado pero más elegante y es lo que uso la mayor parte del tiempo, ya que significa que el programa es autosuficiente y autogestionado y no necesita las tareas del sistema operativo para cuidarlo.

Para saber cómo ejecutar logrotate manualmente y agregarlo a su programa o script, simplemente escriba:

man logrotate

o

logrotate --help

Si está utilizando Python para sus programas, puede comprobar cómo este programa lo utiliza para autoadministrar sus archivos de registro. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Answer 2

Resulta que este es un problema conocido y elboletopermanece abierto mientras escribo esto.

Probablemente lo correcto sea eliminarlos por /etc/logrotate.d/upstartcompleto y rotar los archivos de los servicios individuales individualmente. Debido a que el directorio ( /var/log/upstart/) contiene sólo la salida estándar/stderr de los diversos servicios, y ningún servicio destinado a ejecutarse como undemoniodebería estar saliendo a esos dos canales. Excepto, tal vez, al principio.

En los sistemas que administro, el advenedizo ejecuta tres servicios: php5.6-fpm, php7.1-fpmy acpid. Ninguno de los tres registros está activo, pero a veces el fpm se reinicia debido a que se rota su archivo de registro principal ( /var/log/php5.6-fpm.log), y causa este ruido, porque genera algo de inanidad al inicio.

Si insiste en rotar estos archivos de todos modos, puede confiar en que sus nombres coincidan con los nombres de los servicios y utilizar el siguiente postrotatescript:

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

Para que lo anterior funcione, asegúrese denouse el sharedscriptsverbo allí: mi scriptlet se basa en el hecho de que la ruta real al archivo se le pasará como primer argumento ( $1).

(La redirección a /dev/nulles útil, porque serviceel comando -es ruidoso, y no desea que cron le envíe ese ruido por correo electrónico. Tenga en cuenta que no estoy redirigiendo stderrallí, sólo stdoutque si hay un problema, Aún recibiré tu correo electrónico al respecto.)