*/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命令。
答案 0 :(得分：39)
描述中没有任何内容说明它被执行两次的原因。看别处。
如果它是您正在执行的shell脚本，请将whoami和date附加到日志文件中。你应该能够找到原因。
键入ps -A，确保crond没有运行两次。
答案 1 :(得分：8)
The wget in crontab has often a limit of 15 minutes. In our case this was just the case, and after those 15 minutes the job ends up with a timeout and then re-runs again right away. So, the solution to this was to set up the cronjob in crontab somewhat like this :
1 2 * * * root wget --read-timeout=3600 -O - 'http://cron-job-url' >/dev/null 2>&1
...instead of
1 2 * * * root wget -O - 'http://cron-job-url' >/dev/null 2>&1
So, wget is the thing. Meaning 3600 = 1 hour then. Or more if you need!
答案 2 :(得分：3)
如果它是您安装的应用程序的命令，则可能已将相同的条目添加到/etc/crontab或/etc/cron.d/<something>。
答案 3 :(得分：3)
我确认 - 我的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 reloader
/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
编辑：
我注意到，作为开始日期（今天是Jun24）的cron进程报告Jun06之一
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
第二个流程报告正确（服务器uprime约40分钟 - 我最近重新启动它） 一个重要信息 - 它是在主机上运行的V服务器。
无论我做什么（/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
我已经完成了旧的流程，问题就解决了。
答案 4 :(得分：1)
可以肯定的是，它不是导致它运行两次的crontab条目。找出正在发生的事情的最快方法是在cron作业脚本中添加一些调试。如果不执行任何操作，则默认情况下cron输出将邮寄到root@localhost（除非您将其配置为不同），因此假设您具有root访问权限，请向脚本添加一些调试信息，例如： / p>
echo "Script starting"
date
whoami
并查看输出。这将让你开始弄清楚这是如何被调用两次。
答案 5 :(得分：1)
我遇到了同样的问题，在我的情况下，我错误地初始化了两次cron服务。在我停止了cron # /etc/init.d/crond stop并再次启动它# /etc/init.d/crond start之后，它完美无缺。
我希望这可以帮助任何人。
答案 6 :(得分：0)
看起来你有两个crond正在运行，一个用PID 12512，另一个用PID 12516。
答案 7 :(得分：0)
我使用OpenWrt。
我有同样的问题，但我只有一个cron： ps | 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
logread | 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
答案 8 :(得分：0)
由于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
清楚地评论两个问题之一可以解决问题
答案 9 :(得分：0)
运行ps -A | grep cron，杀死所有工作对我来说并没有帮助。 问题是在杀死所有cron作业并仅使用一个cron守护程序重新启动之后，我将从同一个父cron PPID开始执行两个cron作业-一个使用/ bin / bash-另一个使用/ bin / sh
解决方案是重新启动服务器。
这发生在几次，不同的操作系统上-centos 6和redhat 7。 通常是在在线操作系统升级后无需重启。
正如某人所说-可能是一些不同的背景。
我在网上看到一篇文章，该文章具有相同的处理过程，其中一篇文章使用/ bin / bash进行了完全相同的处理；另一篇文章使用/ bin / sh进行了同一时间-我以为是-这是我的情况-但是，伙计甚至都没有想到这种奇怪行为的根本原因是什么，刚刚开始编写一些脚本逻辑以使第二个进程退出，但这并不是真正的解决方案。
BTW ps -A | grep cron还将列出所有cron子项-正常的cron作业，更多的cron进程并不意味着它是更多的cron守护程序，可能只是一个守护程序，而其他则是孩子。
ps -ef |另一方面，grep cron仅列出一个-为什么？ 因为ps -ef将子级列为CROND-要使它们全部都执行ps -ef | grep -i cron
答案 10 :(得分：0)
我最近从vixie-cron迁移到cronie，并注意到我的根crontab与我的用户crontab文件重复。
以用户和root身份执行/运行“ crontab -e”，并检查文件以确保没有发出重复的命令。
以根用户身份：
以用户身份： $ crontab -e
如果文件非常相似，则最好在不需要的crontab内容中插入“＃TEST”注释，以确保在删除crontab文件的内容之前不存在符号链接或其他异常情况。
答案 11 :(得分：0)
我认为 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脚本。一切都很好。