如何检查已在脚本中处理过的文件,以便我不再处理这些文件？和/或
我现在这样做的方式有什么问题？

你好,
我使用环形缓冲区选项运行tshark以在5MB或1小时后转储到文件.我写了一个python脚本来读取XML中的这些文件并转储到数据库中,这很好.

我的问题是,这实际上是流程密集的,当转换为XML时,其中一个5MB可以变成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行处理哈希比较.
提前致谢.

解决方法:

处理/处理随机创建的文件的好方法是使用
incron而不是cron. (注意：因为incron使用Linux内核
inotify系统调用,此解决方案仅适用于Linux.)

虽然cron根据日期和时间运行工作,但incron运行的工作基于
受监控目录中的更改.例如,您可以配置incron来运行a
每次创建或修改新文件时都有作业.

在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文件可能如下所示：

/var/ss01/ IN_CLOSE_WRITE /path/to/processing/script.py $#
/var/ss02/ IN_CLOSE_WRITE /path/to/processing/script.py $#
/var/ss03/ IN_CLOSE_WRITE /path/to/processing/script.py $#
/var/ss04/ IN_CLOSE_WRITE /path/to/processing/script.py $#

然后,要使用incrond守护程序注册此配置,您就可以运行了

incrontab /path/to/incron_config

这里的所有都是它的.现在,无论何时在/ var / ss01,/ var / ss02,/ var / ss03或/ var / ss04中创建文件,该命令

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

运行,$#替换为新创建的文件的名称.

这将消除存储/比较哈希的需要,文件只会在创建后立即处理一次.

只需确保您的处理脚本不会写入受监控目录的顶层.
如果是,则incrond将注意到创建的新文件,并再次启动script.py,将您发送到无限循环.

incrond监视各个目录,并不递归监视子目录.所以你可以指示tshark写入/ var / ss01 / tobeprocessed,使用incron来监控
/ var / ss01 / tobeprocessed,并让你的script.py写入/ var / ss01,例如.

PS.还有一个用于inotify的python接口,称为pyinotify.与incron不同,pyinotify可以递归地监视子目录.但是,在您的情况下,我不认为递归监视功能是有用的或必要的.