我的 Slackware 14.2 x86_64（Linux 版本 5.12.10）服务器上的 crond（日期为 13Feb21）出现问题。
我有一个脚本，crond 每分钟运行一次，该脚本访问外部设备以获取当前数据并将其记录到文件中。我将脚本命名为 Script1，它运行良好。
我还有另一个脚本，它每分钟运行一次，每次运行脚本时都会处理一个更大的文件。因此，脚本每次运行的时间也更长。这个脚本也运行良好，我将其称为 Script2。这两个脚本没有关联，并且两个脚本之间没有共享文件。
最近我注意到 Script1 只是每隔一分钟将数据记录到数据文件中，而不是每分钟一次。我终于找到了问题所在，但不确定这是否是一个真正可以解决的问题，还是我对 crond 工作原理的误解。
当 Script2 正在处理的文件变得足够大时，该脚本需要一分钟以上的时间才能运行。使用“crond –l debug”来监控 crond 正在做什么，似乎如果 Script2 在下一分钟开始时仍在运行，它就不会启动 Script1，因此不会记录任何数据。然而更奇怪的是，还有其他几个脚本应该每分钟运行一次，但它们也没有启动。
我印象中 crond 只查看当前时刻计划运行的任务，而忽略任何过去计划的任务。现在的情况是，如果某个脚本在下一分钟仍在运行，那么它在接下来的一分钟内不会执行任何操作。当 crond 在调试模式下运行时，cron 日志显示在接下来的一分钟内完全没有活动。只有在下一分钟，当 Script2 不再运行时，crond 活动才会恢复正常。
有人能告诉我发生了什么事吗？
谢谢
答案1
经过几个小时的搜索，我偶然发现了一篇帖子，其中一位用户遇到了一个问题，问题通过使用“#!/bin/bash”而不是“#!/bin/sh”作为 shebang 来解决。由于不确定我使用了哪一个，并且为了寻找救命稻草，我检查了导致问题的脚本。我发现在我最后的一次编辑中，我一定是在某个时候无意中按了空格键，因为我的 shebang 读的是“#!/bin/bash”。它没有影响脚本的运行方式，但它肯定会弄乱 crond。现在一切都很好，但这不是我会很快忘记的一个教训。也许这会拯救另一个用户，使他们免于以后遭受类似的痛苦。