`tail -f` иногда перестает обновляться - и файл не перемещается

10

Недавно я заметил, что иногда tail -f <logfile>перестает обновляться на экран.

Делая Ctrl>- Cи перезапуская все tailработает нормально, все же. И я проверил, чтобы убедиться, что файл журнала не вращается в середине потока (что может привести к tailсумасшествию).

Что вызвало бы это? Я использую RHEL 5.2 x64.

logging rhel5 tail

— кроличий садок
источник

Это происходит на всех лог-файлах или только на определенных? На какой файловой системе находится файл журнала? Какое приложение пишет файл журнала? Вы рассчитали время, чтобы увидеть, происходит ли это либо (1) через определенный промежуток времени после запуска команды tail; или (2) через определенные фиксированные интервалы (например, всегда в: 00: 10: 20: 30: 40 и: 50 после часа)?

— daveadams

@daveadams - насколько я заметил, он был только на двух (по одному на каждом из двух серверов): в данном случае, файл журнала dataminer для BSAE (инструмент отчетности) на сервере HPSA Core (автоматизация центра обработки данных) и server.log для BSAE на хосте отчетов

— Уоррен

1

Кроме того, tail -F продолжит работать, даже если файл будет удален, а затем полностью заменен другим файлом.

— Sirex

6

Попробуйте добавить команду 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 раз, чтобы освободить место в вертикальном направлении, затем подождите, пока он не прекратит работу. Надеюсь, на выходе будут некоторые подсказки.

— Davey
источник

9

Попробуйте использовать:

tail --follow=name <logfile>

И посмотри, работает ли это лучше. Вам не нужно беспокоиться о том, что это будет повернуто из-под вас.

Какой-нибудь шаблон, чтобы это остановить? Определенная продолжительность времени? Определенное время суток?

— MikeyB
источник

файл не выворачивается из-под tail- он просто периодически (иногда между 2 и 20 часами) перестает следовать за ним ... хотелось бы, чтобы был еще шаблон: - \

— warren

Если вы нажмете другие клавиши на клавиатуре (кроме Ctrl-C), это станет лучше? Когда он остановится, вы можете попробовать подключиться к нему, используя strace / ltrace / etc. чтобы увидеть, если он что-то делает.

— MikeyB

хорошая мысль о страсе - ни ввод, ни другие ключи также ничего не дают; Иногда мне нравится оставлять хвост запущенным в screenсеансе для расширенной отладки, и это вызывает беспокойство

— Уоррен

1

Ах ... возможно, это не ваша проблема, но убедитесь, что вы случайно не оставили окно экрана открытым в режиме копирования с запущенным tail -f. Режим копирования в конце концов сделает блок вывода команды (когда буфер заполнится).

— MikeyB

Отличный ответ. Конечно, мои файлы вращались в начале каждого часа!

— Алекс

4

Учитывая, что оба проблемных файла журнала записываются разными компонентами одного и того же приложения, мне интересно, не является ли это какой-то частью кода ведения журнала для этого приложения, вызывающего проблему. Я предлагаю два теста, чтобы лучше понять, что происходит:

Обратите внимание на inode logfile ( ls -i logfile) до запуска хвоста, и, как только хвост завершится неудачей, проверьте его еще раз. Если индекс изменился, то регистратор переписывает весь лог-файл, что нарушит соединение tail.
Обратите внимание на последнюю строку, прежде чем tail перестает работать, а затем зайдите в файл и найдите первую запись в журнале после этой строки. Сделайте это 3-5 раз, если это возможно. Если проблема заключается в том, что программа ведет запись в журнал, скорее всего, это та часть программы, которая записала запись в журнал сразу после того, как вы увидели, что разрыв файла завершен. Если эта запись в журнале всегда одна и та же или если она исходит от одного и того же компонента программы, у вас может быть достаточно данных, чтобы отправить отчет о проблеме поставщику приложения.

Удачи.

— daveadams
источник

3

Имея ту же проблему здесь.

Проблема была в том, что файл, который я смотрю, был смонтирован с другой машины. Уведомление об изменении не было распространено через монтирование.

Решением было использовать хвост на оригинальной машине.

— Стефан Хойер
источник