crontab 的奇怪行为一群答案

【问题标题】：Weird behaviour with crontab an flockcrontab 的奇怪行为一群
【发布时间】：2017-11-27 18:23:38
【问题描述】：

我试图只运行一个程序实例，这是我的 运行脚本，它是从 crontab 调用的：

#!/bin/bash

exec 9>./lockfile
if ! flock -n 9  ; then
   echo "another instance of $0 is running";
   exit 1
fi

node $(dirname $0)/init.js

crontab中的行如下：

*/5 * * * * /bin/bash /path/to/proyect/runner.sh >> /path/to/proyect/logs/output.log 2>> /path/to/proyect/logs/error.log

奇怪的是，在我终止进程后，文件保持锁定状态

【问题讨论】：

锁绑定到一个单独的inode。如果有人运行了，比如说，rm ./lockfile，那么这会将文件句柄打开的 inode 从文件系统中解开。听起来很熟悉？
如果你的 cron 在单独的文件系统命名空间中运行（systemd 等工具支持），它也可能有一组不同的工作目录，而不是在它之外可见。确定 shell 访问您的系统将是微不足道的，但尝试通过问答式会话跟踪所有变量可能会有点痛苦。
...另外，错误，愚蠢的问题，但是当您的 cron 作业运行时，您是否肯定知道. 是哪个目录？我想知道您是否持有 /lockfile，并且您在 cron 之外的各种测试一直在修改不同目录中的 lockfile。
无论如何——我建议确保你将stderr重定向到你实际看到的地方，这样你就可以看到flock（或前面的exec命令）发出的任何错误消息在 cron 作业执行期间；然后类似地记录stat ./lockfile 的输出，并将inode 编号与您在cron 之外获得的编号进行比较。
对不起@CharlesDuffy，不了解有关 inode 的部分。我已将输出重定向到我在调试所有这些时正在查看的文件

【解决方案1】：

奇怪的是，在 vim 中打开文件并保存会解锁文件。这只发生在使用kill -9 pid从cli中杀死进程时@

【讨论】：

这是因为 vim 通过写入一个新文件并重命名原始文件来保存文件——用相同原始目录条目指向的新 inode 替换它。 kill -9 没有什么特别的东西，也不是特别奇怪（sed -i 的工作方式与许多其他工具一样；这意味着任何读者只能看到旧版本或新版本，而不是介于两者之间的临时文件）。也就是说，您为什么要在 vim 中与锁定文件进行交互？
顺便说一句，这里的问题在于，这意味着您的问题是由您在问题中没有告诉我们您在做什么引起的。这意味着除了你之外没有人可以回答这个问题，因为问题不够完整，无法重现问题。
我确实说过我正在杀死进程，我把它放在答案中以明确当进程失败时不会发生，只有在杀死它时，我仍然不明白为什么当进程不再运行时文件保持锁定状态
使用fuser 命令查看哪些进程仍然留在文件中，并带有文件句柄——大概是你启动的进程，然后杀死了一个子进程。但是我反对的事情（您在问题中根本没有说任何话）是在 vim 中打开并保存锁定文件。
谢谢，我会检查的。是的，不，我一开始并没有这样做，这不是我的问题的一部分，只是因为尝试了一些事情来解锁文件。正如您指出的那样，可能正在发生其他事情，但现在它解决了我的问题