Upstart no vuelve a abrir archivos de registro en la rotación de registros

Usamos el sistema de arranque para administrar nuestros servicios en nuestros servidores Ubuntu. Producen registros que se desconectan a /var/log/upstart/SERVICE_NAME.log

Luego, diariamente, los archivos de registro se rotan utilizando el script de rotación de registro que viene con 12.04 LTS:

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

El problema es que, si bien logrotate mueve los archivos, no parece indicar un arranque para cerrar y volver a abrir los archivos, dejando el proceso de arranque 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 aún estaría allí para los procesos del sistema. Además, preferiría no tener que construir más infraestructura de la que necesito.

Creo que tienes 3 opciones.

1. Modifica 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 existente de logrotate 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 se le permite cambiar la configuración del host os logrotate o agregar al cron.da del sistema operativo del host, su tercera opción es cambiar los scripts o programas para verificar que el archivo existe antes de escribir en el archivo. b) Otra forma es un poco del punto 2 anterior, que es mover sus archivos de registro a otro lugar y dentro de su script o programa, ejecute 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 los trabajos 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 ver cómo este programa lo utiliza para autogestionarse sus archivos de registro. http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

Resulta que este es un problema conocido y el ticket permanece abierto mientras escribo esto.

Lo correcto es, probablemente, eliminarlos por /etc/logrotate.d/upstartcompleto y rotar los archivos de los servicios individuales individualmente. Debido a que el directorio ( /var/log/upstart/) contiene solo el stdout / stderr de los diversos servicios, y ningún servicio destinado a ejecutarse como daemon debería emitirse a esos dos canales. Excepto, tal vez, en el inicio.

En los sistemas de gestión que estoy, tres servicios están a cargo de advenedizo: php5.6-fpm, php7.1-fpm, y acpid. Ninguno de los tres registros está activo, pero a veces el fpm se reinicia debido a que su archivo de registro principal ( /var/log/php5.6-fpm.log) se gira, y causa este ruido, ya que genera algo de locura al inicio.

Si insiste en rotar estos archivos de todos modos, puede confiar en el hecho de que sus nombres coinciden 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 de no usar el sharedscriptsverbo allí: mi scriptlet se basa en el hecho, la ruta real al archivo se le pasará como primer argumento ( $1).

(La redirección hacia /dev/nulles útil, porque service-command es ruidoso y no desea que ese ruido le sea enviado por correo electrónico por cron. Tenga en cuenta que no estoy redirigiendo stderrallí solo stdout, si hay un problema, usted Todavía recibiré su correo electrónico al respecto.)