如何在cron作业中处理新文件

Question

如何检查已在脚本中处理的文件，以便不再处理这些文件？和/或 我现在这样做有什么不对？在

你好， 我正在运行tshark并使用ring buffer选项在5MB或1小时后转储到文件。我编写了一个python脚本，以XML格式读取这些文件并将其转储到数据库中，这很好。在

我的问题是，这是一个真正的过程密集型，其中一个5MB的文件在转换为XML时可以变成一个200MB的文件，所以我不想做任何不必要的处理。在

这个脚本每10分钟运行一次，每次运行处理大约5个文件，因为在扫描创建文件的文件夹中是否有任何新条目，我将文件的哈希值转储到数据库中，下次运行时检查哈希值，如果它不在数据库中，我会扫描该文件。 问题是，这并不是每次都有效，它最终处理的是已经完成的文件。当我检查它一直试图处理的文件的哈希时，它在数据库中的任何地方都没有显示，因此为什么要反复地处理它。在

我正在打印脚本输出中的文件名+哈希：

using file /var/ss01/SS01_00086_20100107100828.cap with hash: 982d664b574b84d6a8a5093889454e59
using file /var/ss02/SS02_00053_20100106125828.cap with hash: 8caceb6af7328c4aed2ea349062b74e9
using file /var/ss02/SS02_00075_20100106184519.cap with hash: 1b664b2e900d56ca9750d27ed1ec28fc
using file /var/ss02/SS02_00098_20100107104437.cap with hash: e0d7f5b004016febe707e9823f339fce 
using file /var/ss02/SS02_00095_20100105132356.cap with hash: 41a3938150ec8e2d48ae9498c79a8d0c 
using file /var/ss02/SS02_00097_20100107103332.cap with hash: 4e08b6926c87f5967484add22a76f220
using file /var/ss02/SS02_00090_20100105122531.cap with hash: 470b378ee5a2f4a14ca28330c2009f56
using file /var/ss03/SS03_00089_20100107104530.cap with hash: 468a01753a97a6a5dfa60418064574cc 
using file /var/ss03/SS03_00086_20100105122537.cap with hash: 1fb8641f10f733384de01e94926e0853
using file /var/ss03/SS03_00090_20100107105832.cap with hash: d6209e65348029c3d211d1715301b9f8 
using file /var/ss03/SS03_00088_20100107103248.cap with hash: 56a26b4e84b853e1f2128c831628c65e 
using file /var/ss03/SS03_00072_20100105093543.cap with hash: dca18deb04b7c08e206a3b6f62262465 
using file /var/ss03/SS03_00050_20100106140218.cap with hash: 36761e3f67017c626563601eaf68a133 
using file /var/ss04/SS04_00010_20100105105912.cap with hash: 5188dc70616fa2971d57d4bfe029ec46 
using file /var/ss04/SS04_00071_20100107094806.cap with hash: ab72eaddd9f368e01f9a57471ccead1a 
using file /var/ss04/SS04_00072_20100107100234.cap with hash: 79dea347b04a05753cb4ff3576883494 
using file /var/ss04/SS04_00070_20100107093350.cap with hash: 535920197129176c4d7a9891c71e0243 
using file /var/ss04/SS04_00067_20100107084826.cap with hash: 64a88ecc1253e67d49e3cb68febb2e25 
using file /var/ss04/SS04_00042_20100106144048.cap with hash: bb9bfa773f3bf94fd3af2514395d8d9e 
using file /var/ss04/SS04_00007_20100105101951.cap with hash: d949e673f6138af2d388884f4a6b0f08

它应该做的唯一文件是每个文件夹一个，所以只有4个文件。这导致不必要的处理，我不得不处理重叠的cron作业+其他服务受到影响。在

我希望从这篇文章中得到一个更好的方法，或者希望有人能告诉我为什么会发生，我知道后者可能很难，因为这可能是一系列的原因。在

这里是code（我不是一个编码器，而是一个系统管理员，所以请注意：p）第30-32行处理哈希比较。 提前谢谢。在

Answer 1

处理/处理随机创建的文件的一个好方法是使用 incron而不是{}。（注意：由于incron使用的是Linux内核 inotifysyscalls，此解决方案仅适用于Linux。）

而cron基于日期和时间运行作业，incron则基于 监视目录中的更改。例如，可以将incron配置为运行 每次创建或修改新文件时的作业。在

在Ubuntu上，这个包名为incron。我不确定RedHat，但我相信这是正确的包：http://rpmfind.net//linux/RPM/dag/redhat/el5/i386/incron-0.5.9-1.el5.rf.i386.html。在

一旦安装了incron软件包，请阅读

man 5 incrontab 

有关如何设置incrontab配置文件的信息。您的incron_config文件可能如下所示：

^{pr2}$

然后在incrond守护进程中注册这个配置，您可以运行

incrontab /path/to/incron_config

就这些了。现在，每当在/var/ss01、/var/ss02、/var/ss03或/var/ss04中创建文件时，命令

/path/to/processing/script.py $#

运行，并将$#替换为新创建的文件的名称。在

这样就不需要存储/比较散列，文件只会被处理一次——在创建之后立即处理。在

只需确保处理脚本不会写入受监视目录的顶层。 如果是这样，incrond将注意到新文件的创建，并启动脚本.py再次，让你进入一个无限循环。在

incrond监视单个目录，而不递归地监视子目录。所以您可以指示tshark写入/var/ss01/tobeprocessed，使用incron进行监视 /var/ss01/to已处理，并将您的脚本.py例如，写入/var/ss01。在

还有一个python接口用于inotify，称为pyinotify。与incron不同，pyinotify可以递归地监视子目录。但是，在您的情况下，我认为递归监视特性没有用处或必要。在

Answer 2

我对这些文件中的内容知之甚少，因此这可能不适用于您，但如果您只有一个目标客户，我建议您使用目录并移动文件以反映其状态。具体来说，你可以有一个dir结构，比如

/waiting
/progress
/done

并使用mv的相对原子性来更改每个文件的“状态”。（我相信mv是否真正是原子的取决于您的文件系统。）

当处理任务要处理文件时，它会将文件从waiting移到{}（并确保移动成功）。这样，没有其他任务可以接收它，因为它不再等待。文件完成后，它将从progress移到done，在那里清理任务可能会删除或归档不再需要的旧文件。在

Answer 3

我看到了几个问题。在

如果有重叠的cron作业，则需要有一个锁定机制来控制访问。一次只允许一个过程来消除重叠问题。您可以设置一个shell脚本来执行此操作。通过创建一个目录来创建一个“锁”（mkdir是原子的），处理数据，然后删除锁目录。如果shell脚本在尝试创建目录时发现该目录已经存在，那么您就知道另一个副本已经在运行，它可以退出。在

如果不能更改cron表，那么只需重命名可执行文件，并将shell脚本命名为与旧可执行文件相同的名称。在

哈希不能保证是文件的唯一标识符，很可能是，但不能绝对保证。在