*/5 * * * * my command
This entry works but every 5 minutes it gets executed twice, why?
In /var/log/cron
it shows:
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!
For sure it's not the crontab entry that's causing it to run twice. The fastest way to find out what is going on is to add some debugging to the cron job script. If you do nothing, then by default the cron output will be mailed to root@localhost
(unless you have configured this to be different), so assuming you have root access, add some debugging information to the script, such as:
echo "Script starting"
date
whoami
and look at the output. This will get you started as to figuring out how this is getting called twice.
I use OpenWrt.
I have the same problem, but I have just one 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
It looks like you have two crond's running, one with PID 12512 and one with PID 12516.
I do confirm - my cron also run twice...
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)
My crontab
grep -R /var/spool/ -e reloader
/var/spool/cron/crontabs/root:* * * * * /etc/apache2/generator/reloader.do
output of:
whoami
date
------
output:
root
root
Tue Jul 24 14:46:02 CEST 2012
---------
Tue Jul 24 14:46:03 CEST 2012
---------
My current workaround is:
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
But it's not the answer why that's happen...
System - gentoo Cron - vixie-cron
part of ps aux wwf
output (lunched inside cron task)
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
EDIT:
I did notice, that one of cron process report Jun06 as start date (today is 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
Second process report correctly (server uprime is ~40 minutes - i did restart it recenty) One important info - it is V-server running on host machine.
No matter what I do (/etc/init.d/vixie-cron restart) it start's with the same PID
SOLVED:
I've found the reason. One V-server was run twice, with different context. Possible explanation - someone has changed the context while machine was running, and as a result, not all processes were killed, and what;s more - they did affect new instance of vserver (context 303 and 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
I've TERM old process, and problem is solved.
I had the same problem due to a double entry in conf file:
# 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
Clearly commenting one of the 2 solves the problem