`tail -f` a volte interrompe l'aggiornamento - e il file non si è spostato

10

Ho notato di recente che a volte tail -f <logfile>smetterà di aggiornare lo schermo.

Fare un Ctrl>- Ce riavviare il sistema tailfunziona bene, però. E ho controllato per assicurarmi che il file di registro non venisse ruotato a metà flusso (il che può far tailperdere la testa).

Cosa causerebbe questo? Sto eseguendo RHEL 5.2 x64.

logging rhel5 tail

— conigliera
fonte

Questo accade su tutti i file di registro o solo su alcuni? Su quale filesystem è il file di log? Quale applicazione sta scrivendo il file di registro? Hai cronometrato l'incapacità di vedere se accade (1) un certo periodo di tempo dopo aver avviato il comando tail; o (2) a determinati intervalli fissi (ad es. sempre a: 00: 10: 20: 30: 40 e: 50 dopo l'ora)?

— daveadams,

@daveadams - per quanto ho notato, è stato solo su due (uno su ciascuno dei due server): in questo caso, il file di registro del dataminer per BSAE (strumento di reportistica) su un server HPSA Core (automazione del data center) e il server.log per BSAE sull'host segnalante

— warren

1

a parte ciò, tail -F continuerà a funzionare anche se il file viene rimosso e successivamente sostituito completamente da un altro file.

— Sirex,

6

Prova a racchiudere il comando tail stracese lo hai:

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

Quindi, solo per i pazzi calci ricorsivi, puoi regolare l'output dello strace (non importa se si interrompe perché esce su un file):

 tail -f /tmp/tail.trace

Il mio sembra:

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,

-T attiva il tempo e -T attiva il tempo trascorso nelle chiamate.

Premi Invio 4 o 5 volte per creare un po 'di spazio verticale, quindi attendi che smetta di muovere. Speriamo che ci saranno alcuni indizi nell'output.

— davey
fonte

9

Prova a usare:

tail --follow=name <logfile>

E vedi se funziona meglio. Non devi preoccuparti che venga ruotato da sotto di te.

Qualche motivo per fermarlo? Certo periodo di tempo? Certo momento della giornata?

— MikeyB
fonte

il file non viene ruotato da sotto tail- è solo periodicamente (tra le 2 e le 20 ore) che smette di seguire più .. vorrei che ci fosse più di uno schema: - \

— warren

Se premi altri tasti sulla tastiera (diversi da ctrl-c), va meglio? Quando si ferma, puoi provare ad attaccarti usando strace / ltrace / etc. per vedere se sta facendo qualcosa.

— MikeyB,

buona riflessione sullo strace - né entrare né altri tasti ottengono che accada nulla; A volte mi piace lasciare una coda in esecuzione in una screensessione per il debug esteso, e questo è preoccupante

— Warren

1

Ah ... forse non è un tuo problema, ma assicurati di non lasciare accidentalmente una finestra dello schermo aperta in modalità copia con tail -f in esecuzione. La modalità Copia alla fine bloccherà l'output del comando (quando il buffer si riempie).

— MikeyB,

Risposta eccellente. Ovviamente i miei file venivano ruotati all'inizio di ogni ora!

— alex

4

Dato che entrambi i file di registro problematici sono scritti da diversi componenti della stessa applicazione, mi chiedo se non sia una parte del codice di registrazione per quell'applicazione a causare il problema. Propongo due test per farsi un'idea di cosa sta succedendo:

Nota l'inode del file di log ( ls -i logfile) prima di iniziare la coda e, una volta che la coda ha esito negativo, ricontrollalo. Se l'inode è stato modificato, il logger sta riscrivendo l'intero file di registro, interrompendo la connessione di coda.
Nota l'ultima riga prima che la coda smetta di funzionare, quindi visita il file e trova la prima voce di registro dopo quella riga. Fatelo 3-5 volte se possibile. Se si tratta di un problema con il programma che esegue la registrazione, la parte del programma che ha scritto la voce di registro immediatamente dopo aver visto la coda è molto probabilmente responsabile. Se la voce del registro è sempre la stessa o se proviene dallo stesso componente del programma, è possibile che si disponga di dati sufficienti per inviare una segnalazione del problema al fornitore dell'applicazione.

In bocca al lupo.

— daveadams
fonte

3

Ho lo stesso problema qua.

Il problema era che il file che stavo guardando era montato da un'altra macchina. La notifica di modifica non è stata propagata attraverso il mount.

La soluzione era usare la coda sulla macchina originale.

— Stephan Hoyer
fonte