# Cron Not Running



## aallord (Jan 12, 2010)

I have a root cron job that according to the logs is running correctly; but when checking notifications in Moodle, there is an error the cron job hasn't run.

This is the root cron file:

```
MAILTO="aallord@***"
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/php -f /usr/home/httpd/domains/www.carroll.edu/site/public_html/moodle10/admin/cron.php >/dev/null
0,15,30,45 * * * * /usr/local/bin/php -f /usr/home/httpd/domains/www.carroll.edu/site/public_html/moodle10/auth/ldap/auth_ldap_sync_users.php >/dev/null
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/php -f /usr/home/httpd/domains/www.carroll.edu/site/public_html/moodle09/admin/cron.php >/dev/null
0,15,30,45 * * * * /usr/local/bin/php -f /usr/home/httpd/domains/www.carroll.edu/site/public_html/moodle09/auth/ldap/auth_ldap_sync_users.php >/dev/null
```

Entering crontab -l lists the same lines above. 

Checking the cron log it indicates the job ran without problems as when there are errors an email is sent to me.

What could I be doing wrong?


----------



## DutchDaemon (Jan 12, 2010)

Can you omit the > /dev/null for a while and check your email for exact output? You say that 'errors are mailed to you', but i think that is only true for the execution of the command itself (i.e.: php is not found, a pathname is incorrect, a file wasn't found, etc.), not for the actual execution of the php code, which may well produce an error on the stdout channel (which gets lost in the bitbucket).


----------



## DutchDaemon (Jan 12, 2010)

BTW: you can replace the first field in cron with */5 and */15, respectively; looks a bittle less crowded.


----------



## aallord (Jan 12, 2010)

I made the suggested changes and no email was sent, cron log still indicated the job is running. When I enter cron start the response is cron: cron already running, pid: 52***. I enter cron stop and the response is the same.

The log indicates cron ran after I revised and reloaded the changes.


----------



## DutchDaemon (Jan 12, 2010)

I don't quite understand why this topic is called 'cron not running'. If the cron log (/var/log/cron) shows that these jobs are executed every 5/15 minutes, cron is definitely running (and `# /etc/rc.d/cron status` or `# pgrep cron` will show that). Note: cron jobs that produce no output at all on stdout will not cause an email to be sent. 

When the problem actually lies with the _php code_ being executed, those commands should be investigated (by running them from the command-line, in a verbose manner if that's possible).

I'm not entirely sure about the combination cron (with its limited path) and system calls being executed by php code (which may call programs not in cron's default path), so I guess you could add this to the top of the crontab:


```
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
```


----------



## aallord (Jan 12, 2010)

The title was determined based on even though the log appears to show cron is running, yes there is a pid for cron; no results come.

In regards to the commands, the commands have been run verbose on several occasions and run without error. As was just checked as I write this response. I have to run them manually now until cron starts to run them as Moodle and the college I work for depends on those running in those time periods.

So now I ask, is it cron isn't running or is it the commands? Since the commands run verbose from the command line, how could it be a php or command issue?

I would copy the results, but the post would get quite long from the results of these scripts. They send messages, update users and post information from the Moodle system. 

Is there something with not being able to stop cron causing the problem?


----------



## Alt (Jan 12, 2010)

Is your mail system working at all? Try to send email to yourself from shell:

```
echo test | mail aallord@***
```
Also, you can check /var/log/maillog to see how mail is goin


----------



## aallord (Jan 12, 2010)

After entering 


```
echo test | mail aallord@***
```

The error was clearly "Permission denied". I revised so sendmail had correct permissions and then the code above worked fine.

Now the email from when cron runs is:

"debug DTEST is on, not exec'ing command.
	cmd='/usr/local/bin/php -f /usr/home/httpd/domains/www.carroll.edu/site/public_html/moodle10/admin/cron.php' shell='/bin/sh'"

How do I turn off debug DTEST?


----------



## Alt (Jan 12, 2010)

man cron
-x parameter
perhaps you must edit /etc/rc.conf and restart cron


----------



## aallord (Jan 12, 2010)

Solved...

The way this had to be fixed, enter:

```
ps ax | grep cron
```
to determine the process id cron was running on:

```
kill processid
cd /etc/rc.d
cron start
```
The problem was based on cron being started using cron -x test which placed cron in debug mode. While in debug mode, cron would run the schedule but not process any scripts.

Thanks Alt for pointing me in the direction of checking sendmail. This allowed the emails from cron to be sent showing me where the problem was. Then some research to find out how to stop the debugging resulted in the information here.

Thanks for the help, problem solved.


----------



## phoenix (Jan 12, 2010)

Don't start/stop things like that.

Just use the RC script:  `# /etc/rc.d/cron stop; /etc/rc.d/cron start`


----------



## Beastie (Jan 13, 2010)

Isn't *re*start the same as a stop followed by a start?


----------



## Alt (Jan 13, 2010)

Not always =)


----------



## Beastie (Jan 13, 2010)

Then rc.d(8) is inaccurate?


> Each script is expected to support at least the following arguments, which are automatically supported if it uses the *run_rc_command*() function:
> [...]
> *restart*  Perform a *stop* then a *start*.


So it's officially a requirement for not being a rogue rc. 
Plus /etc/rc.d/cron uses *run_rc_command "$1"*.

I also haven't seen an rc failing to stop and start when given the restart command... so far.


----------



## Alt (Jan 13, 2010)

Yes they must stop and start, but for some rc it may be overriden to send signal for example.. Anyway, in our case it must work ok =) Question is aallord started cron not from an rc script at all =)


----------



## aallord (Jan 13, 2010)

The reason for stopping cron using the kill process wasn't by first choice. 

When using cron stop or cron restart the message given was simply an indication cron was already running and the process id; it wouldn't stop or restart.

Options were at that time to reboot the server, which given the time of day and the use of this application server; wasn't an option; that left the kill process to get cron working correctly again.

Yes, the kill process and then cron start restored the cron stop and cron restart commands.


----------



## phoenix (Jan 13, 2010)

`# cron start` and `# cron stop` are **NOT** the same as running `# /etc/rc.d/cron start` and `# /etc/rc.d/cron stop`.

The first two commands try to run /usr/sbin/cron, which will always tell you that the command is already running.  /usr/sbin/cron does not support a "stop" or "stop" option.

The last two commands run the actual RC script.


----------

