tail -f有时会停止更新-并且文件没有移动


10

我最近注意到,有时tail -f <logfile>会停止更新到屏幕。

不过,执行Ctrl>- C并重新启动tail工作正常。而且我检查了一下,以确保日志文件没有在中游时旋转(这会使您tail失去理智)。

是什么原因造成的?我正在运行RHEL 5.2 x64。


这是在所有日志文件上发生还是在某些日志文件上发生?日志文件位于哪个文件系统上?哪个应用程序正在编写日志文件?您是否已对故障进行计时,以查看是否发生以下情况?(1)在启动tail命令之后的一段时间内;或者 或(2)以一定的固定间隔(例如始终在小时后的:00:10:20:30:40和:50间隔)?
daveadams '02

@daveadams-据我所知,它仅位于两个服务器上(两个服务器中的每个服务器上):在这种情况下,HPSA Core服务器(数据中心自动化)上的BSAE(报告工具)的dataminer日志文件报告主机上BSAE的server.log
沃伦

1
顺便说一句,即使删除文件,然后完全替换为另一个文件,tail -F也将继续工作。
Sirex'2

Answers:


6

strace如果有,请尝试使用tail命令包装:

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打开呼叫所花费的时间。

按回车4或5次,以留出一些垂直空间,然后等待其停止拖尾。希望输出中会有一些线索。


9

尝试使用:

tail --follow=name <logfile>

看看效果更好。您不必担心它会从您身下旋转出来。


任何模式停止吗?一定的时间长度?一天中的某些时间?


该文件不被旋转出从下面tail-它只是周期性停止跟随了..希望能有更多的模式的(有时为2至20小时): - \
沃伦

如果您按键盘上的其他键(Ctrl-c除外)会更好吗?当它停止时,您可以尝试使用strace / ltrace / etc附加到它。看看它在做什么。
MikeyB

在strace上考虑周全-输入和其他键都不会发生任何事情;有时我喜欢在screen会话中运行tail-f 进行扩展调试,这令人担忧
warren,

1
啊……可能不是您的问题,但请确保不要意外地在运行tail -f的情况下以复制模式打开屏幕窗口。复制模式将最终使命令输出块(当缓冲区填满时)。
MikeyB 2011年

极好的答案。当然,我的文件会在每个小时的顶部轮换出来!
Alex

4

鉴于两个有问题的日志文件都是由同一应用程序的不同组件编写的,所以我想知道不是引起该问题的那个应用程序的日志记录代码的某些部分。我建议进行两个测试,以更好地了解正在发生的事情:

  • ls -i logfile在启动尾部之前,请注意日志文件()的索引节点,一旦尾部发生故障,请再次检查它。如果索引节点已更改,则记录器将重写整个日志文件,这将中断tail的连接。

  • 注意尾巴停止工作之前的最后一行,然后访问该文件并在该行之后找到第一个日志条目。如果可能,请这样做3-5次。如果程序在执行日志记录时出现问题,则很可能是在看到断尾后立即写入日志条目的程序部分。如果该日志条目始终相同,或者它来自程序的同一组件,则您可能有足够的数据向应用程序供应商提交问题报告。

祝好运。


3

这里有同样的问题。

问题是,我正在观看的文件是从另一台计算机挂载的。更改通知未通过安装传播。

解决方案是在原始机器上使用拖尾。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.