Rotar un registro del vigilante VPN sin romper el escritor
Decida primero el destino y luego haga que la rotación coincida con cómo el escritor abre el archivo: renombrar para comprobaciones breves, reabrir o copytruncate para un demonio.
Una comprobación de estado de VPN que añade una línea por minuto crea en silencio un segundo deber: decidir cómo esas líneas salen del disco. Arreglar el túnel no hace nada por ese deber, y renombrar el archivo no redirige un proceso que todavía tiene el descriptor antiguo. Responda primero la cuestión del destino y luego haga que la rotación coincida con la forma en que el escritor lo abre.
Elija el destino antes que la política de rotación
Una unidad de systemd que ya envía su salida al diario mantiene la retención en un solo lugar. journald aplica límites como SystemMaxUse y MaxRetentionSec , así que un vigilante que registra allí hereda un límite sin trabajo adicional. Añadir un segundo archivo sin límite junto a él duplica el mantenimiento sin ninguna ganancia.
Un archivo dedicado se gana su lugar cuando algo más lo lee: un analizador, una exportación de auditoría o una página que espera una ruta estable. Una vez tomada esa decisión, el archivo necesita un propietario, un modo y una política de rotación escritos juntos, porque los tres solo son correctos como conjunto. Una ruta que cualquiera puede crear es también una ruta que cualquiera puede reemplazar, así que los permisos del directorio pertenecen a la misma nota. Escriba todo eso junto a la comprobación y la próxima edición empezará desde los mismos hechos.
Escriba el bloque para que coincida con el escritor
Parta de un escritor que abre la ruta en cada invocación, añade una línea y sale. Ese patrón sobrevive a la rotación sin ninguna cooperación del proceso, porque la siguiente ejecución abre el archivo que ahora está en esa ruta. El bloque de abajo conserva una semana de versiones y vuelve a crear el archivo con el propietario y el modo que el escritor necesita:
/var/log/vpn-watchdog.log {
daily
rotate 7
create 0600 root root
missingok
notifempty
}
El manual de logrotate define el recuento como el número de versiones rotadas conservadas, no como una garantía de siete días de historial, y la palabra clave daily se evalúa cuando se ejecuta la tarea en lugar de actuar como su propio planificador. En la mayoría de las distribuciones un temporizador de systemd o una entrada de cron ya posee esa invocación, así que compruebe cuál existe antes de añadir un segundo. Acertar con la propiedad importa más que el recuento de retención. Copiar un modo solo para root en un archivo escrito por una cuenta de servicio detiene el registro en la siguiente rotación, y el fallo aparece horas después como una marca de tiempo obsoleta en lugar de como un error. Confirme el usuario del escritor antes de copiar un bloque de otro sitio.
Un escritor que nunca reabre necesita otra solución
Un proceso de larga duración con un descriptor abierto sigue escribiendo en el inodo renombrado. El espacio no se libera y el archivo visible deja de crecer, lo que parece una rotación rota hasta que se comprueba el inodo. O enseñe al proceso a reabrir, o haga que la rotación copie y trunque en lugar de renombrar.
La ruta de reapertura es la más limpia donde el software la admite: envíe la señal documentada o ejecute el comando documentado, y deje que el proceso abra él mismo el archivo nuevo. La alternativa es copytruncate , que copia el contenido al nombre rotado y luego trunca el original en su sitio, de modo que el descriptor sigue siendo válido pero las escrituras que caen entre la copia y el truncado se pierden.
Para unidades iniciadas por systemd, apunte StandardOutput al diario o a un archivo y deje que la unidad posea el ciclo de vida. Un bucle de shell que añade mediante tee -a sin límite de tamaño es la disposición que llena una partición durante una avería, porque una comprobación fallida suele registrar mucho más que una sana.
Pruebe la rotación sin esperar al temporizador
El modo de depuración informa de lo que ocurriría y no toca nada, lo que lo convierte en la primera ejecución segura después de una edición. Fuerce una rotación real cuando esté satisfecho y luego confirme que la siguiente línea del registro cae en el archivo nuevo y no en el renombrado:
logrotate -d /etc/logrotate.d/vpn-watchdog logrotate -f /etc/logrotate.d/vpn-watchdog ls -l /var/log/vpn-watchdog.log* tail -n 3 /var/log/vpn-watchdog.log df -h /var/log
Lea la salida en ese orden. La pasada de depuración debería nombrar el archivo y las acciones que pretende; una ejecución forzada debería producir el nombre rotado que esperaba; la cola debería mostrar una entrada nueva después de que el escritor vuelva a ejecutarse. Un valor de df creciente con un archivo visible que encoge significa el problema de descriptor descrito arriba.
Repita la ejecución forzada dos veces para ver cómo se comporta la retención cuando ya existen versiones. Borrar el archivo más antiguo es el resultado esperado, y una eliminación ausente suele significar que el recuento o el comodín del nombre rotado no coinciden con lo que logrotate creó.
Conserve una reversión y un registro escrito
Guarde el bloque anterior antes de editar y anote qué planificador lo ejecuta, porque una reversión que restaura el archivo pero no el temporizador reproduce la mitad del problema original. Rote una vez a mano tras restaurar y luego confirme que la cuenta del escritor puede escribir en la ruta del registro. Si el servicio se ejecuta bajo systemd, recargue la unidad después de cualquier cambio en la redirección de su salida, ya que el proceso en marcha sigue escribiendo al objetivo antiguo. Lea usted mismo las siguientes líneas del registro en lugar de confiar en que la unidad volvió limpia.
Registre el modo, el propietario, el recuento de retención y el presupuesto de disco esperado junto a la propia comprobación. Cuando más adelante la comprobación pase de un script de una sola vez a un demonio, la política de rotación tiene que cambiar con ella, y esa nota es la que dice a la siguiente persona qué suposición se rompió.
Por último, mantenga la decisión del registro separada de la decisión de recuperación. Una sonda fallida debe seguir la política de recuperación de la propia conexión, no una regla escondida dentro de logrotate, y ninguna disposición de registro debería ser la razón para reiniciar un túnel que funciona.