Я недавно заметил, что иногда tail -f <logfile> перестанет обновляться до экрана.
Делая Ctrl>-C и перезапуск tail хотя работает нормально. И я проверил, не поворачивается ли файл журнала в середине потока (что может tail потерять рассудок).
Что могло бы вызвать это? Я использую RHEL 5.2 x64.
Попробуйте использовать:
tail --follow=name <logfile>
И посмотрите, работает ли это лучше. Вам не нужно беспокоиться о том, что он вывернется из-под вас.
Есть ли какая-то закономерность в его остановке? Определенный промежуток времени? Определенное время суток?
Попробуйте обернуть свою команду tail с помощью strace если он у вас есть:
strace -Tt -o /tmp/tail.trace tail -f /var/log/messages
Тогда просто для сумасшедших рекурсивных ударов вы можете отслеживать вывод strace (не имеет значения, если он сломается, потому что он переходит в файл):
tail -f /tmp/tail.trace
Мой выглядит так:
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 включает время, а -T включает время, затраченное на звонки.
Нажмите return 4 или 5 раз, чтобы освободить немного вертикального пространства, затем подождите, пока он перестанет следовать. Надеюсь, в выводе будут какие-то подсказки.
Учитывая, что оба проблемных файла журнала записываются разными компонентами одного и того же приложения, мне интересно, не является ли часть кода ведения журнала для этого приложения причиной проблемы. Я предлагаю два теста, чтобы лучше понять, что происходит:
Обратите внимание на индексный дескриптор файла журнала (ls -i logfile) перед запуском хвоста, и если хвост выходит из строя, проверьте его снова. Если индексный дескриптор изменился, то регистратор перезаписывает весь файл журнала, что нарушит соединение хвоста.
Обратите внимание на последнюю строку перед тем, как tail перестанет работать, а затем посетите файл и найдите первую запись журнала после этой строки. По возможности проделайте это 3-5 раз. Если это проблема с программой, ведущей журнал, скорее всего, виновата та часть программы, которая записала запись в журнал сразу после того, как вы видите разрыв хвоста. Если эта запись в журнале всегда одна и та же или поступает из одного и того же компонента программы, у вас может быть достаточно данных для отправки отчета о проблеме поставщику приложения.
Удачи.
Здесь та же проблема.
Проблема заключалась в том, что просматриваемый мной файл был смонтирован с другой машины. Уведомление об изменении не распространялось через монтирование.
Решением было использовать хвост на оригинальной машине.