*/5 * * * * my command
此条目有效，但每 5 分钟执行两次，为什么？
在/var/log/cron 中显示：
Jun 16 22:20:01 Test CROND[12512]: (root) CMD (my command)
Jun 16 22:20:01 Test CROND[12516]: (root) CMD (my command)
所以不是来自两个用户。
仅使用crontab -e -u root 输入一次。该命令是一个php命令。
【问题讨论】：
标签： cron
描述中没有给出执行两次的理由。看看别处。
如果您正在执行的是 shell 脚本，请将其附加到日志文件中 whoami 和 date。你应该能找出原因。
输入 ps -A | grep crond，确保 crond 没有运行两次。
【讨论】：
crontab 中的 wget 通常有 15 分钟的限制。在我们的案例中，情况就是这样，在这 15 分钟之后，作业以超时结束，然后立即重新运行。因此，解决方案是在 crontab 中设置 cronjob，如下所示：
1 2 * * * root wget --read-timeout=3600 -O - 'http://cron-job-url' >/dev/null 2>&1
...而不是
1 2 * * * root wget -O - 'http://cron-job-url' >/dev/null 2>&1
所以，wget 就是这样。意思是 3600 = 1 小时。或者更多，如果你需要！
【讨论】：
确定不是 crontab 条目导致它运行两次。找出发生了什么的最快方法是在 cron 作业脚本中添加一些调试。如果你什么都不做，那么默认情况下 cron 输出将被邮寄到root@localhost（除非你已经将它配置为不同），所以假设你有 root 访问权限，在脚本中添加一些调试信息，例如：
echo "Script starting"
date
whoami
并查看输出。这将使您开始弄清楚它是如何被调用两次的。
【讨论】：
如果它是您安装的应用程序的命令，可能它已经将相同的条目添加到/etc/crontab 或/etc/cron.d/<something>。
【讨论】：
/etc/cron.d 中还有一个文件调用了一个非常相似但不完全相同版本的同一个调用。追尾结束了，回到手头的工作。 :)
我确实确认 - 我的 cron 也运行了两次...
Jul 24 14:40:01 localhost cron[2713]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:41:01 localhost cron[9481]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:41:01 localhost cron[10724]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:42:01 localhost cron[20380]: (root) CMD (/etc/apache2/generator/reloader.do)
Jul 24 14:42:01 localhost cron[20832]: (root) CMD (/etc/apache2/generator/reloader.do)
我的 crontab
grep -R /var/spool/ -e 重载
/var/spool/cron/crontabs/root:* * * * * /etc/apache2/generator/reloader.do
输出：
whoami
date
------
输出：
root
root
Tue Jul 24 14:46:02 CEST 2012
---------
Tue Jul 24 14:46:03 CEST 2012
---------
我目前的解决方法是：
if [ -f /etc/apache2/generator/reloader.lock ]
then
exit
fi
touch /etc/apache2/generator/reloader.lock
/etc/apache2/generator/reloader
rm /etc/apache2/generator/reloader.lock
但这不是为什么会发生这种情况的答案......
系统 - gentoo cron - vixie-cron
ps aux wwf 输出的一部分（在 cron 任务中午餐）
root 10843 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 29797 0.0 0.0 25020 964 ? S 15:08 0:00 \_ /usr/sbin/cron
root 29799 0.0 0.0 9188 1228 ? Ss 15:08 0:00 \_ /bin/bash /etc/apache2/generator/reloader
root 29822 0.0 0.0 14800 988 ? R 15:08 0:00 \_ ps aux wwf
------
root 8215 0.0 0.0 16480 836 ? Ss 14:23 0:00 /usr/sbin/cron
root 31419 0.0 0.0 25020 968 ? S 15:08 0:00 \_ /usr/sbin/cron
root 31423 0.0 0.0 9188 1228 ? Ss 15:08 0:00 \_ /bin/bash /etc/apache2/generator/reloader
root 31431 0.0 0.0 14804 1004 ? R 15:08 0:00 \_ ps aux wwf
编辑：
我确实注意到，其中一个 cron 进程报告 Jun06 作为开始日期（今天是 Jun24）
root 10843 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 8215 0.0 0.0 16480 836 ? Ss 14:23 0:00 /usr/sbin/cron
第二个进程报告正确（服务器正常运行时间约为 40 分钟 - 我最近确实重新启动了它） 一个重要信息 - 它是在主机上运行的 V-server。
无论我做什么（/etc/init.d/vixie-cron restart）它都以相同的 PID 开始
已解决：
我找到了原因。 一个 V-server 运行了两次，使用不同的上下文。 可能的解释 - 有人在机器运行时更改了上下文，因此并非所有进程都被杀死，还有什么 - 他们确实影响了 vserver 的新实例（上下文 303 和 3031）：
root 10843 3031 developer 0.0 0.0 16480 560 ? Ss Jun06 0:01 /usr/sbin/cron
root 16509 303 developer 0.0 0.0 16480 836 ? Ss 15:18 0:00 /usr/sbin/cron
我已经 TERM 旧流程，问题已解决。
【讨论】：
我曾经遇到过同样的问题，在我的情况下，我错误地初始化了 cron 服务两次。在我停止 cron # /etc/init.d/crond stop 并再次启动它 # /etc/init.d/crond start 后，它运行良好。
我希望这可以帮助任何人。
【讨论】：
我以为 cron 两次启动了我的 bash 脚本，但我错了。我想我会为了（希望）他人的利益而分享我的经验。这让我有点摸不着头脑......
在 cron 启动的那一刻，“ps aux”输出从显示我的脚本运行的 0 个实例变为两个实例，或者乍一看似乎是这样：
kdeen 1797750 0.0 0.0 2608 600 ? Ss 15:52 0:00 /bin/sh -c /home/kdeen/bin/once-a-day-local.sh
kdeen 1797751 0.0 0.0 19520 3488 ? S 15:52 0:00 /bin/bash /home/kdeen/bin/once-a-day-local.sh
但仔细看，我发现一个实例是 /bin/sh -c，另一个是 /bin/bash。这是正确的行为。我的脚本以“#!/bin/bash”开头，但 cron 总是使用 /bin/sh 运行东西。所以有一个“sh”启动器进程，然后是我的 bash 脚本。都很好。
【讨论】：
我使用 OpenWrt。
我有同样的问题，但我只有一个 cron ： 附言 | grep crond：
31447 root 1508 S /usr/sbin/crond -c /etc/crontabs -l 8
31454 root 1500 S sh -c ps | grep crond
31456 root 1496 S grep crond
日志读取 | grep cron
May 27 13:15:01 decibox cron.info crond[31447]: crond: USER root pid 1594 cmd /root/check_connect.php.sh
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2103 cmd /root/check_connect.php.sh
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2325 cmd /root/check_connect.php.sh
May 27 13:25:01 decibox cron.info crond[31447]: crond: USER root pid 2880 cmd /root/check_connect.php.sh
【讨论】：
由于 conf 文件中的双重输入，我遇到了同样的问题：
# grep /syslog /etc/rsyslog.conf /etc/rsyslog.d/50-default.conf
/etc/rsyslog.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
/etc/rsyslog.d/50-default.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
明确评论 2 个中的一个可以解决问题
【讨论】：
运行 ps -A | grep cron，杀死所有工作对我来说没有帮助。 问题是在杀死所有 cron 作业并仅使用一个 cron 守护程序重新开始之后，我会从同一个父 cron PPID 开始两个 cron 作业 - 一个使用 /bin/bash - 另一个使用 /bin/sh
解决办法是重启服务器。
这发生在好几次，不同的操作系统 - centos 6 和 redhat 7。 通常在在线操作系统升级后无需重启。
正如有人所说 - 可能是一些不同的背景。
我在网上看到一篇文章，其中一篇与 /bin/bash 的进程相同，另一篇与 /bin/sh 完全相同 - 我想是的 - 这是我的情况 - 但不，这家伙甚至没有给出想到了这种奇怪行为的根本原因是什么，刚刚开始编写一些脚本逻辑以使第二个进程退出，这并不是真正的解决方案。
顺便说一句 ps -A | grep cron 还将列出所有 cron 子进程 - 正常的 cron 作业，更多的 cron 进程并不意味着它有更多的 cron 守护进程，可能只有一个守护进程，而其他守护进程是子进程。
ps -ef |另一方面，grep cron 只列出一个 - 为什么？ 因为 ps -ef 将孩子列为 CROND - 让他们都做 ps -ef | grep -i cron
【讨论】：
我最近从 vixie-cron 迁移到 cronie，发现我的根 crontab 是我的用户 crontab 文件的副本。
以用户和 root 身份执行/运行“crontab -e”，并检查文件以确保没有发出重复的命令。
作为根：
作为用户： $ crontab -e
如果文件非常相似，最好在不需要的 crontab 内容中插入“# TEST”注释，以确保在删除 crontab 文件的内容之前不存在符号链接或其他异常。
【讨论】：
看起来你有两个 crond 正在运行，一个是 PID 12512，一个是 PID 12516。
【讨论】：