问题标签 [pyinotify]

我遇到以下情况：

• pyinotify 监视文件中的 IN_CLOSE_WRITE 事件
• 我更改文件中的某些内容并保存
• 事件被触发
• 我阅读了文件，发现它没有任何变化

稍微修改了一下，我注意到它在调试时工作正常。我在读取文件的行上设置了一个断点，从而增加了一点延迟。之后 - 文件被读取并且更改在那里。

因此，似乎添加time.sleep(1)或以其他方式延迟执行可以解决问题。否则我会收到一个过早的 IN_CLOSE_WRITE 事件。

我想知道该事件是在提交更改并关闭文件之后触发，还是在此之前触发。IN_CLOSE_WRITE 之后似乎没有其他相关事件。同时，文档有点棘手：

使用 IN_CLOSE_WRITE 因为如果发出相应文件上的所有更改都将安全地写入文件中

我提交了一份关于常见问题解答中措辞的错误报告，但与此同时，我想就此事获得一些额外的意见。这应该发生吗？解决它的“道德正确”方法是什么？

所有这一切都发生在 Linux Mint 15 x64 上。

我需要监听远程服务器的文件事件FTP。我发现pyinotify可以检测Python. 它在本地文件系统上检测良好，我认为它非常好。

但是当我给它一个FTP地址让它看时，它没有看到合适的路径并给了我；

我也试过 url ftp://myuser@myserver，但结果是一样的。

那么，我缺少什么pyinotify，是否可以使用 pyinotify 通过 FTP 监听文件更改？

如果它不可用，您能否建议另一个库来执行此操作？

谢谢

我在我的主目录（/home/name）下放置了一个使用 pyinotify 的脚本并运行它。虽然我不能让脚本监视我的主目录 (/home/name) 或包含我的主目录的目录，例如 root (/) 和 /home/。所有其他目录都可以，例如 /var、/boot、/home/name/Documents。

让我用干净的方式描述它：

脚本：

我有 pserve --reload 可以处理任何 python 更改，但是当我更改模板时我仍然需要手动重新加载。

我制作了这个小脚本来监视我的模板文件夹是否有任何更改，但是重新加载 pserve 的命令是什么？如果我需要从我的 Pyramids 项目中调用 pserve 方法，比如init .py 或其他什么，我会调用什么方法来重新加载 pserve？

我有很多关于使用 pyinotify 作为守护进程启动脚本的问题。

我有一些这样的代码：

我现在的问题是，如果我将 daemonize 参数设置为 True，这是否意味着整个脚本作为守护进程运行，还是只是 pyinotify？

如果它只是 pyinotify 我将如何将整个脚本作为守护进程运行？

如果我将脚本作为守护进程运行，是否真的有必要让 pyinotify 成为守护进程？

我的最后一个问题是，如果 pyinotify 是守护进程，我肯定需要回调吗？就我而言，我只希望脚本永远运行并且仅在系统重新启动/重新启动时被杀死。

该脚本还应该像任何标准启动脚本一样运行，无需人工干预。

供参考，

我正在运行 Ubuntu 12.04 服务器。

在此先感谢，导航

Is there any way to print a watched file modification ? let's take an example: I'm monitoring file.txt, Pyinotify can tell me that it has been modified, but It can't seem to be able to output what changes occured ? Am I wrong ? How can I see what changes has been made to a file that I'm monitoring ?

Big thanks in advance, sorry for my bad english.

I am trying to make a simple piece of software that automatically makes a list based on the file contents of any newly inserted USB memory stick.

using ubuntu 14.04.

now using os.listdir() and glob.glob() work fine on their own...

however when using it with pyinotify, and getting the input_dir for the os.listdir() or glob.glob() from the event.pathname ... I just get a blank list every time...

tried concatenating strings to add single quotes, double quotes etc... to no avail.

here's a snippet of code

我目前正在使用 pyinotify 来监视 irssi（用于 linux 命令行的 irc 客户端）日志文件，并且该日志文件是 irssi 使用 pyinotify 的 IN_MODIFY 掩码写入的，它读取文件就好了，并且每次都被告知它改变了，但我试图在一行中找到一个特定的短语，在这一行中，这个短语是：

现在我有代码可以检查最后一行是否存在，但是 irssi 有时会以块的形式写入日志文件，因为由于它是机器人读数，所以事情会同时出现。这段代码工作正常，我遇到的问题是找到最接近底部的最后一行，其中包含 COMPLETE: 短语。

我知道我可能做错了，但我想出的方法（它不起作用，所以我做错了）是保存最后一个 COMPLETE: 行并搜索该行并 for loop enumerate在具有行号偏移量的文件上找到最后一行，然后处理每个完整的行。以下是代码，如果有人有任何想法，或者可能有更好的方法，将不胜感激！

编辑：

self.extractdata 是一个函数，用于对我得到的行的某些部分进行正则表达式，该行从 getlastline 函数发送到 self.extractdata，而 self.setlast 仅设置 self.lastline 并打印一些用于测试的东西。

我正在使用 Celery 3.1.16 代理（运行 RabbitMQ）和多个 Celery 工作人员，其中 celeryd 通过主管进行了守护。问题在于任务更新。当我更新我的 tasks.py 文件时，celery worker 运行旧代码。

芹菜启动命令：

我在 django settings.py 中包含任务文件：

pyinotify已安装并且可以工作（我猜是这样），它是 celery 日志的一部分：

所以，我的问题是：如果它们被修改，如何获取 celery 更新和应用新任务代码？

I'm running apache with django and mod_wsgi enabled in 2 different processes.

I read that the second process is a on-change listener for reloading code on change, but for some reason the ready() function of my AppConfig class is being executed twice. This function should only run once.

I understood that running django runserver with the --noreload flag will resolve the problem on development mode, but I cannot find a solution for this in production mode on my apache webserver.

I have two questions:

1. How can I run with only one process in production or at least make only one process run the ready() function ?

2. Is there a way to make the ready() function run not in a lazy mode? By this, I mean execute only on on server startup, not on first request.

For further explanation, I am experiencing a scenario as follows: The ready() function creates a folder listener such as pyinotify. That listener will listen on a folder on my server and enqueue a task on any changes. I am seeing this listener executed twice on any changes to a single file in the monitored directory. This leads me to believe that both processes are running my listener.