Question

我正在使用tail -F log | python parse.py来监视和解析不断增长的日志文件，但是可能会因为从日志文件中读取不完整的行而导致一些解析错误。

tail是否可能发出不完整的行？

在解析器中，我正在阅读包含如下代码的行：

import csv
import sys

reader = csv.reader(sys.stdin)
for row in reader
    # process

Answer 1

尾部可能会发出“不可解的行” - 但前提是无效行写入文件。这是一个循环的论点，但这里有一个如何发生的例子：

你尾巴-f on / var / log / syslog
syslog-ng在一个块跨越写入的过程中死亡（扇区为512字节，你的文件系统块大小很可能更大，也可能不比4096大得多..所以，syslog有9k的数据缓存写出，它通过4k字节页面，然后它可以写下接下来的4k + 1k系统日志死。至少在ext2上，即使在fsck之后，这最终会成为部分写入.ext3？..呵呵。我我已经做了很长时间的嵌入我不记得了...但是，我希望不要......但是谁说你写的数据总是正确的？你可能会得到一个非致命的字符串格式错误，不包含您期望的换行符。
然后你会有一个没有以换行符（或者甚至是\ 0）终止的部分行，并且下次syslog启动并开始追加它时，只会附加到结尾处没有'有效'记录概念的文件。所以第一个新记录将是垃圾，但下一个将是好的。

这很容易锻炼..

在一个窗口中

tail -f SOMEFILE

在另一个窗口中

echo FOO >>SOMEFILE
echo BAR >>SOMEFILE
printf NO_NEWLINE >>SOMEFILE
echo I_WILL_HAVE_THE_LAST_LINE_PREFIXED_TO_ME_CAUSING_NERD_RAGE >>SOMEFILE

由于Linux的尾部默认使用inotify，所以读取的内容将在没有换行符的情况下获得最后一行并等到下一个换行符附加NO_NEWLINE到它认为是“最新行”的开头。

如果你想这样做'pythonic'方式，如果你使用Linux - 使用inotify，如果你使用OSX或BSD使用'knotty'并且否定使用'tail'作为输入管道只是自己看文件。

如果你也使用'resync on truncate'，Tail可能会做一些奇怪的事情 - 即如果文件在读取过程中被归零并重新启动，你可能会在读取时得到一些奇怪的数据，因为'tail'会关闭先前打开的文件句柄以换取新文件句柄。

Answer 2

既然你改变了我的问题..新答案！：P

reader = csv.reader(sys.stdin)
for row in reader: 
    try:
        validate_row_data_somehow(row)
        do_things_with_valid_row(row)
    except:
        print "failed to process row", `row`

“tail”有可能发出不完整的线条吗？

2 个答案: