我们在服务器上有一项常规工作，该工作会创建一些文件/tmp并且完成后不会删除它们。由于我不想深入的原因，我们无法修改作业来删除文件。所以我想创建一个定期删除这些文件的 cronjob。为了不干扰正在运行的作业，它应该只删除超过一天的文件。我想出了以下命令：
find /tmp/myprefix* -mtime +1 -delete
如果我在终端中测试它，效果很好，所以我用 cron 安排它：
0 1 * * * find /tmp/myprefix* -mtime +1 -delete
现在，如果它在凌晨 1 点运行，它似乎会忽略该-mtime参数并删除以 开头的所有文件myprefix，从而干扰正在运行的作业。
有谁知道为什么会发生这种情况？
备注：由于该作业仅在晚上运行，因此我的测试全部执行，而没有作业运行。我刚刚检查了昨晚完成的工作的文件是否仍然存在。也许这就是原因，并且文件的修改时间以一种奇怪的方式设置，而文件仍然被写入？
我知道明显的解决方案是安排白天进行清理，但我仍然对问题的原因感兴趣。
编辑
根据 Kusalanandas 的建议，我将昨晚的 cron 条目更改为：
0 1 * * * find /tmp/myprefix* -mtime +1 -ls > /tmp/find.out
/tmp/find.out今天早上该文件为空。这是预期的行为，因为没有足够旧的文件。但根据过去的观察，如果我用-delete“太年轻”的文件运行它，就会被删除。
编辑2
最后一次测试后，我将第二天晚上的命令更改为
0 1 * * * find /tmp/myprefix* -mtime +2 -delete
按照+2我的预期，前一天晚上创建的文件都不会被删除。虽然这些文件确实保留了下来，但今晚的文件已被删除。现在我确信-mtime如果文件仍然被写入，检查不会按预期运行。这仍然是一个谜，为什么-ls前一天晚上没有输出任何东西。也许我会尝试再次运行-exec和ls以获得更多细节。但在我的两周假期之前我还有一次尝试:-)
答案1
Cron 条目看起来只是像另一个 bash 行，但事实并非如此。尝试将查找语法放入单独的脚本中，然后执行，例如：
echo "find /tmp/myprefix* -mtime +1 -delete" > /my/path/cronscript.sh chmod 755 /my/path/cronscript.sh
并将 cron 行编辑为： 也可能需要进行0 1 * * * /my/path/cronscript.sh
一些调整。chown / chgrp此外，如果您在/etc/crontab档案中工作，username则需要其他信息：0 1 * * * username /my/path/cronscript.sh