'tail -f' às vezes pára de atualizar - e o arquivo não foi movido

Question

Tenho notado recentemente que às vezes tail -f <logfile> parará de atualizar na tela.

Fazer um Ctrl > - C e reiniciar o tail funciona bem. E eu verifiquei se o arquivo de log não está sendo rotacionado midstream (o que pode fazer com que tail perca a cabeça).

O que causaria isso? Estou executando o RHEL 5,2 x64.

    

Answer 1

Tente envolver seu comando tail com strace se você tiver:

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

Então, apenas para chutes recursivos malucos, você pode ajustar a saída da strace (não importa se isso é interrompido porque está indo para um arquivo):

 tail -f /tmp/tail.trace

Parece o meu:

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,

O -t liga a hora e -T muda o tempo gasto em chamadas.

Pressione 4 ou 5 vezes para fazer um pouco de espaço vertical, depois espere que ele pare de seguir. Espero que haja algumas pistas na saída.

    

Answer 2

Tente usar:

tail --follow=name <logfile>

E veja se isso funciona melhor. Você não precisa se preocupar com isso sendo girado para fora de você.

Algum padrão para parar? Certo período de tempo? Certa hora do dia?

    

Answer 3

Dado que ambos os arquivos de log problemáticos são escritos por componentes diferentes do mesmo aplicativo, eu me pergunto se não é alguma parte do código de registro para aquele aplicativo que está causando o problema. Proponho dois testes para ter uma ideia melhor do que está acontecendo:

• Observe o inode do arquivo de log ( ls -i logfile ) antes de iniciar a cauda, e quando a cauda falhar, verifique novamente. Se o inode foi alterado, o criador de logs está reescrevendo todo o arquivo de log, o que quebraria a conexão da cauda.

• Observe a última linha antes que a cauda pare de funcionar e, em seguida, visite o arquivo e localize a primeira entrada de registro após essa linha. Faça isso de 3 a 5 vezes, se possível. Se é um problema com o programa fazendo o log, a parte do programa que escreveu a entrada de log imediatamente após você ver a quebra de cauda é mais provável responsável. Se essa entrada de log for sempre a mesma ou se for proveniente do mesmo componente do programa, você poderá ter dados suficientes para enviar um relatório de problemas ao fornecedor do aplicativo.

Boa sorte.

    

Answer 4

Tendo o mesmo problema aqui.

O problema é que o arquivo que estou assistindo foi montado em uma máquina diferente. A notificação de alteração não foi propagada pela montagem.

A solução foi usar a cauda na máquina original.