`tail -f` a veces deja de actualizarse, y el archivo no se ha movido

10

He notado recientemente que a veces tail -f <logfile>dejará de actualizarse a la pantalla.

Sin embargo, hacer un Ctrl>- Cy reiniciar el trabajo tailfunciona bien. Y verifiqué para asegurarme de que el archivo de registro no se gira a mitad de camino (lo que puede hacer que tailpierda la cabeza).

¿Qué causaría esto? Estoy ejecutando RHEL 5.2 x64.

logging rhel5 tail

— madriguera
fuente

¿Esto sucede en todos los archivos de registro o solo en algunos? ¿En qué sistema de archivos está el archivo de registro? ¿Qué aplicación está escribiendo el archivo de registro? ¿Ha programado la falla para ver si ocurre (1) un cierto período de tiempo después de que inició el comando de cola; o (2) a ciertos intervalos fijos (por ejemplo, siempre a: 00: 10: 20: 30: 40 y: 50 después de la hora)?

— daveadams

@daveadams: hasta donde he notado, solo ha estado en dos (uno en cada uno de los dos servidores): en este caso, el archivo de registro de dataminer para BSAE (herramienta de informes) en un servidor HPSA Core (automatización del centro de datos) y el server.log para BSAE en el host de informes

— warren

1

además, tail -F continuará funcionando incluso si el archivo se elimina y luego se reemplaza por otro archivo por completo.

— Sirex

6

Intente ajustar su comando de cola con stracesi lo tiene:

strace -Tt -o /tmp/tail.trace tail -f /var/log/messages

Luego, solo para patadas recursivas locas, puede ajustar la salida de strace (no importa si eso se rompe porque está saliendo a un archivo):

 tail -f /tmp/tail.trace

El mío se ve así:

8:39:00 write(1, "ng SMAC\n", 8)       = 8 <0.000026>
18:39:00 read(3, "", 0)                 = 0 <0.000019>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 fstatfs64(3, 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=4807069, f_bfree=1924458, f_bavail=1680271, f_files=1221600, f_ffree=820806, f_fsid={-1331083162, -1313908385}, f_namelen=255, f_frsize=4096}) = 0 <0.000021>
18:39:00 inotify_init()                 = 4 <0.000033>
18:39:00 inotify_add_watch(4, "/var/log/messages", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 <0.000041>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 read(4,

El -t activa el tiempo y -T activa el tiempo dedicado a las llamadas.

Presione regresar 4 o 5 veces para hacer un poco de espacio vertical, luego espere a que deje de seguir. Esperemos que haya algunas pistas en la salida.

— davey
fuente

9

Intenta usar:

tail --follow=name <logfile>

Y mira si eso funciona mejor. No tiene que preocuparse de que se gire debajo de usted.

¿Algún patrón para que se detenga? Cierto período de tiempo? Cierta hora del día?

— MikeyB
fuente

el archivo no se está girando desde abajo tail, es solo periódicamente (en algún momento entre 2 y 20 horas) deteniéndose para seguir más ... desearía que hubiera más de un patrón: - \

— warren

Si presiona otras teclas en el teclado (aparte de ctrl-c), ¿mejora? Cuando se detenga, puede intentar adjuntarlo usando strace / ltrace / etc. para ver si está haciendo algo.

— MikeyB

buen pensamiento sobre la pista: ni enter ni otras teclas consiguen que algo suceda tampoco; A veces me gusta dejar una cola en ejecución en una screensesión para una depuración extendida, y esto es preocupante

— Warren

1

Ah ... posiblemente no sea tu problema, pero asegúrate de no dejar accidentalmente una ventana de pantalla abierta en modo copia con tail -f corriendo. El modo de copia eventualmente bloqueará la salida del comando (cuando el buffer se llene).

— MikeyB

Excelente respuesta ¡Por supuesto, mis archivos se rotaban en la parte superior de cada hora!

— alex

4

Dado que ambos archivos de registro problemáticos están escritos por diferentes componentes de la misma aplicación, me pregunto si no es parte del código de registro de esa aplicación lo que está causando el problema. Propongo dos pruebas para tener una mejor idea de lo que está sucediendo:

Tenga en cuenta el inodo del archivo de registro ( ls -i logfile) antes de comenzar la cola, y una vez que la cola falla, revísela nuevamente. Si el inodo ha cambiado, entonces el registrador está reescribiendo todo el archivo de registro, lo que rompería la conexión de la cola.
Tenga en cuenta la última línea antes de que la cola deje de funcionar, y luego visite el archivo y encuentre la primera entrada de registro después de esa línea. Haga esto 3-5 veces si es posible. Si se trata de un problema con el programa que realiza el registro, la parte del programa que escribió la entrada del registro inmediatamente después de que ve un salto de cola probablemente sea el responsable. Si esa entrada de registro es siempre la misma, o si proviene del mismo componente del programa, es posible que tenga suficientes datos para enviar un informe del problema al proveedor de la aplicación.

Buena suerte.

— daveadams
fuente

3

Teniendo el mismo problema aquí.

El problema era que el archivo que estoy viendo se montó desde una máquina diferente. La notificación de cambio no se propagó a través del montaje.

La solución fue usar la cola en la máquina original.

— Stephan Hoyer
fuente