Cron Not Running

A

aallord

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:
Code: 
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?
 
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).
 
BTW: you can replace the first field in cron with */5 and */15, respectively; looks a bittle less crowded.
 
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.
 
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:

Code: 
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 
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?
 
Is your mail system working at all? Try to send email to yourself from shell:
Code: 
echo test | mail aallord@***
Also, you can check /var/log/maillog to see how mail is goin
 
After entering

Code: 
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?
 
Solved...

The way this had to be fixed, enter:
Code: 
ps ax | grep cron
to determine the process id cron was running on:
Code: 
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.
 
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.
Click to expand...
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.
 
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 =)
 
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.
 
# 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.
 
You must log in or register to reply here.
Back
Top