rsyslog con logrotate: vuelva a cargar rsyslog vs copytruncate

Estoy trabajando en Ubuntu 14 con la utilidad predeterminada rsyslog y logrotate.

En la configuración predeterminada de rsyslog logrotate /etc/logrotate.d/rsyslogveo lo siguiente:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Por lo que entiendo, se recomienda usar copytruncate en todos los escenarios de logrotate, ya que no mueve el registro actual, sino que trunca el registro para que cualquier proceso con un controlador de archivo abierto pueda seguir escribiendo en él.

Entonces, ¿cómo es que la configuración predeterminada utiliza la función de recarga rsyslog en su lugar?

Para responder a su pregunta, primero debe comprender las diferentes compensaciones de recarga y truncamiento:

• recargar : se cambia el nombre del archivo de registro anterior y se notifica el proceso de escritura en ese registro (a través de la señal Unix) para volver a crear su archivo de registro. Este es el método de sobrecarga más rápido / más bajo: las operaciones de cambio de nombre / movimiento son muy rápidas y tienen un tiempo de ejecución constante. Además, es una operación casi atómica: esto significa que (casi) no se perderá ninguna entrada de registro durante el movimiento / recarga. Por otro lado, necesita un proceso capaz de recargar y volver a abrir su archivo de registro. Rsyslog es un proceso de este tipo, por lo que la configuración predeterminada de logrotate utiliza el método de recarga. El uso de este modo con rsyslog es altamente recomendado por rsyslog aguas arriba.
• copytruncate : el archivo de registro anterior se copia en un archivo de almacenamiento y luego se trunca para "eliminar" las líneas de registro antiguas. Si bien la operación de truncado es muy rápida, la copia puede ser bastante larga (dependiendo de qué tan grande sea su archivo de registro). Además, se puede perder alguna entrada de registro durante el tiempo entre la operación de copia (recuerde, puede ser lenta) y el truncamiento. Por estas razones, copytruncate no se usa por defecto para servicios capaces de recargar y recrear sus archivos de registro. Por otro lado, si un servidor no es capaz de recargar / recrear archivos de registro, copytruncate es su apuesta más segura. En otras palabras, no requiere ningún soporte de nivel de servicio. El proyecto ascendente rsyslog desaconseja firmemente el uso de este modo.

Hablando como autor de rsyslog, copytruncate es en realidad una muy, muy, muy mala elección. Es intrínsecamente picante y su uso es casi una garantía de que perderá datos de registro. Cuanto más frecuentemente se escriba en el archivo, más perderá. Y esto no es solo parte de la última línea, sino que puede ser varios cientos, dependiendo de la sincronización exacta y el estado del sistema en el momento en que ocurre la rotación.

Cuando se mueve el archivo y se crea un nuevo inodo (archivo), rsyslog realiza un seguimiento del archivo anterior y completa el procesamiento. Entonces no tienes ninguna pérdida en este caso. Garantizado (excepto si desmonta el sistema de archivos ...).

En "reopenOnTruncate": Personalmente, he visto que reopenOnTruncate también es picante en otros aspectos, especialmente con NFS y similares. Hace algún tiempo, eliminé totalmente esa funcionalidad, pero luego fui persuadido para que volviera a fusionar una funcionalidad similar. Se mantendrá "experimental" probablemente para siempre, ya que realmente sé que la gente tiene problemas en sistemas muy cargados. "copytruncate" simplemente no es un modo decente para trabajar con archivos de registro.

Actualmente trabajo en la refactorización de archivos (ETA 8.34 o 8.35). La versión refactorizada probablemente podrá evitar el reenvío accidental debido a la carrera API, pero tampoco puede proteger contra la pérdida de datos, porque esto es conceptualmente imposible.

Esto depende completamente de cómo el proceso está escribiendo registros.
copytruncatesolo funciona si los mensajes de registro se agregan al archivo (p whatever >> logfile. ej .,
y no cuando se redirige la salida (p whatever > logfile. ej .).

Desde la versión 8.16, rsyslog tiene una opción de archivo reopenOnTruncateque maneja el problema de copytruncte.

Para rsyslog específicamente, probablemente tenga más sentido dejar las cosas como están.

La razón básica es que rsyslog tiene colas internas que puede usar en casos donde su manejador de salida no está disponible.

La recarga a) hará que rsyslog vuelva a crear su propio archivo de registro, yb) hará que los eventos en cola se vacíen al archivo en la creación.

Puede ser que el copytruncate no dañe (aunque me preocuparía que las líneas parcialmente escritas se truncaran), pero tendería a pensar que copiar / eliminar / recargar es 'más seguro' desde un punto de vista de integridad.

Como mencionó @ faker , dado que rsyslog puede manejar la situación en la que su archivo no está disponible, no hay una razón convincente para usar copytruncate.

Y como mencionó @ SelivanovPavel , rsyslog en realidad requiere una configuración específica para manejar la copia truncada correctamente.

Entonces, si solo porque usar el reloadenfoque requiere menos desviación de la configuración predeterminada, lo mantendría.