☰

cron 忽略对 /etc/crontab 的更改

tag-icon • tag-icon cron
cron 忽略对 /etc/crontab 的更改

我看到了奇怪的 cron 行为，我不确定如何调试和修复。

它会忽略更改，/etc/crontab直到重新启动，例如我编辑/etc/crontab添加

* * * * * root echo 'weee' > /tmp/stupidcron

然后：

root@linux-plba:~# sleep 270 && ls /tmp/stupidcron ls: cannot access /tmp/stupidcron: No such file or directory

添加任何crontab实用功能的东西都可以。

如果我重新启动 cron，更改将被应用，但任何后续更改都要等到下次重新启动才会生效。

我将根邮件重定向到我的收件箱，但那里没有任何有趣的内容。我在系统日志中也没有看到任何内容。

我发现最接近此问题的是 FreeBSD 邮件列表中的这个旧帖子：

http://lists.freebsd.org/pipermail/freebsd-questions/2010-September/221179.html

该 cron 是 Vixie cron 4.1-194.209.1 x86-64

也许有人见过这样的行为或者知道如何进一步调试/修复它？

PS 我确实阅读了有关它的社区维基：为什么我的 crontab 不工作？我该如何排除故障？我相信该文没有涉及此案。

答案1

好吧，看来这个问题没有真正的答案。

我的同事决定降级 cron 并看看会发生什么，结果发现它运行良好。

因此，他查看了 SRPM 中旧版本和新版本的 spec 文件，发现它似乎是破坏 cron 的补丁之一：

* Wed Aug 6 2014 [email protected] - Fix cron man page being ambiguous bnc#853010: * bnc#853010-manpage-ambiguous.patch - Fix wrong mtime when reruning cron scripts bnc#879734: * bnc#879734-directory-mtime.patch

由于跟踪显示 cron做stat 文件及其获取的结构是正确，这是 cron 问题，而不是配置错误/权限问题等。

答案2

当你使用 crontab -e （添加 cron 任务的标准方法）时，你可能注意到你正在编辑一个临时文本文件. 退出 crontabs 后已安装自动。Crontab 将为 中的每个用户创建一个文件/var/spool/cron/crontabs。当然，cron 守护程序/etc/crontab也会查找。

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.ZRmGzQ/crontab installed on Mon May 12 07:50:40 2014)

这是 中的一个用户文件的标题/var/spool/cron/crontabs。它表示编辑该文件不会起作用。还/tmp/crontab.ZRmGzQ/crontab表示上次更新时 crontab -e 使用的临时文件。

sysadmin@omg:~$ crontab -l > tmp-cron.txt
sysadmin@omg:~$ echo '*/1 * * * * echo "APOEL ULTRAS" >> /tmp/stupidcron' >> tmp-cron.txt
sysadmin@omg:~$ crontab tmp-cron.txt
sysadmin@omg:~$ sleep 150 && cat /tmp/stupidcron
APOEL ULTRAS
APOEL ULTRAS

在这里，我将当前的 crontab 导出到临时文件 tmp-cron.txt，添加 crontab 并再次安装该文件。工作正常。

因此，基本上，你的情况中的 crontab 不起作用，因为它没有已安装。

只是当心当你安装新的文本文件时，旧文件会被覆盖。在操作前请备份你的文件。

相关内容