Question

*/5 * * * * my command

This entry works but every 5 minutes it gets executed twice, why?

In /var/log/cron it shows:

Jun 16 22:20:01 Test CROND[12512]: (root) CMD (my command)
Jun 16 22:20:01 Test CROND[12516]: (root) CMD (my command)

So it's not from two users.

It is only entered once with crontab -e -u root. The command is a php command.

Was it helpful?

Solution

Nothing in the description gives reason for it to be executed twice. Look elsewhere.

  • Do two users call it?
  • Is it entered twice?
  • Does it call itself?
  • Does it set in motion conditions for repetition?

If it's a shell script you're executing, have it append whoami and date to a log file. You should be able to dig up the reason.

UPDATE

Type ps -A, make sure crond isn't running twice.

OTHER TIPS

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!

If it's a command for an application you installed, maybe it already added the same entry to /etc/crontab or /etc/cron.d/<something>.

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.

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 had the same problem once, in my case was that I initialize the cron service twice by mistake. After I stopped cron # /etc/init.d/crond stop and started it again # /etc/init.d/crond start, it worked perfectly.

I hope this can help anybody.

It looks like you have two crond's running, one with PID 12512 and one with PID 12516.

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

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top