Às vezes, o `tail -f` para de atualizar - e o arquivo não foi movido

10

Eu notei recentemente que algumas vezes tail -f <logfile>deixará de atualizar para a tela.

Fazer um Ctrl>- Ce reiniciar o tailtrabalho bem, no entanto. E verifiquei para garantir que o arquivo de log não estivesse sendo girado no meio do caminho (o que pode fazer com que se tailperca).

O que causaria isso? Estou executando o RHEL 5.2 x64.

logging rhel5 tail

— Warren
fonte

Isso acontece em todos os arquivos de log ou apenas em alguns? Em que sistema de arquivos está o arquivo de log? Qual aplicativo está gravando o arquivo de log? Você cronometrou a falha para ver se isso acontece (1) um certo período de tempo após o início do comando tail; ou (2) em determinados intervalos fixos (por exemplo, sempre às: 00: 10: 20: 30: 40 e: 50 após a hora)?

— Daveadams

@daveadams - até onde eu notei, ele só está em dois (um em cada um de dois servidores): nesse caso, o arquivo de log do dataminer para BSAE (ferramenta de relatório) em um servidor HPSA Core (automação do datacenter) e o server.log para BSAE no host de relatório

— warren

1

como um aparte, a cauda -F continuará funcionando mesmo que o arquivo seja removido e posteriormente substituído por outro arquivo completamente.

— Sirex 16/02

6

Tente agrupar seu comando tail, stracese 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 do strace (não importa se isso quebra porque está saindo para um arquivo):

 tail -f /tmp/tail.trace

O meu se parece com:

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 ativa o tempo e -T ativa o tempo gasto nas chamadas.

Pressione retorno 4 ou 5 vezes para criar um pouco de espaço vertical e aguarde até que ele pare de seguir. Espero que haja algumas pistas na saída.

— davey
fonte

9

Tente usar:

tail --follow=name <logfile>

E veja se isso funciona melhor. Você não precisa se preocupar com isso ser rotacionado de baixo de você.

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

— MikeyB
fonte

o arquivo não está sendo rotacionado por baixo tail- é apenas periodicamente (em algum momento entre 2 e 20 horas) parando para seguir mais .. desejo que houvesse mais de um padrão: - \

— warren

Se você pressionar outras teclas do teclado (além de ctrl-c), ele melhora? Quando parar, você pode tentar anexá-lo usando strace / ltrace / etc. para ver se está fazendo alguma coisa.

— 8118 MikeyB

bom pensamento sobre o traço - nem a tecla Enter nem outras teclas fazem com que algo aconteça; Às vezes eu gostaria de deixar um tail-f correndo em um screensessão de depuração estendida, e isso é preocupante

— Warren

1

Ah… possivelmente não é seu problema, mas certifique-se de não deixar acidentalmente uma janela de tela aberta no modo de cópia com o tail -f em execução. O modo de cópia fará o bloco de saída do comando eventualmente (quando o buffer for preenchido).

— 9608 MikeyB às

Excelente resposta. É claro que meus arquivos estavam sendo rotacionados no máximo a cada hora!

— alex

4

Dado que ambos os arquivos de log problemáticos são gravados por diferentes componentes do mesmo aplicativo, será que não é parte do código de log desse aplicativo que está causando o problema? Proponho dois testes para ter uma idéia melhor do que está acontecendo:

Observe o inode do arquivo de log ( ls -i logfile) antes de iniciar a cauda e, uma vez que a cauda falhe, verifique novamente. Se o inode foi alterado, o criador de logs está reescrevendo todo o arquivo de log, o que interromperia a conexão da cauda.
Observe a última linha antes que a cauda pare de funcionar e, em seguida, visite o arquivo e encontre a primeira entrada de log após essa linha. Faça isso 3-5 vezes, se possível. Se houver algum problema com o programa que faz o log, a parte do programa que escreveu a entrada do log imediatamente após a quebra da cauda é provavelmente a responsável. Se essa entrada de log for sempre a mesma ou se vier do mesmo componente do programa, você poderá ter dados suficientes para enviar um relatório de problemas ao fornecedor do aplicativo.

Boa sorte.

— daveadams
fonte

3

Estou tendo o mesmo problema aqui.

O problema era que o arquivo que eu estava assistindo foi montado em uma máquina diferente. A notificação de alteração não foi propagada através da montagem.

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

— Stephan Hoyer
fonte