A few of our Cron based programs are not executing!
To be exact: most programs specified to run in our Cron Tab schedule are running OK, but 2 programs are not! Also, I have manually run these programs and they run fine, so there is no problem with these programs themselves and the only problem is that for some reason Cron Tab does not run these 2 programs! What could that be? How can we find what the problem is?
FYI: we do have a new line after each of these programs so that quirky problem of Cron is not the case here. The programs look like:
Well this program is supposed to do a bunch of things, that is how. Such as it is to Populate a MySQL Table with 1000s of values.It is NOT doing that via the Cron program for this purpose.
FYI, again when I run this program manually it does work Ok and does Populate a MySQL Table with 1000s of values.
Chances are great (if not to say 100%) that the commands are run by cron, but somehow fail. Cron doesn’t just decide to ignore commands for no reason.
So the question is why it is failing. I would start with putting
MAILTO=you@example.com
At the top of the cron file, and remove the > /dev/null from the command, so it will email any output to you so you can see what’s happening.
Most likely it’s some sort of environment issue, because cron runs in a different environment than you as a logged in user do. So you might for example assume that something is in your $PATH, which it is when you’re logged in, but it might not be there for cron.
no - it will send you an email when the cron is executed so that you can confirm that it is in fact running even though it doesn’t appear to be doing anything.
With luck the email will contain some sort of error message to indicate where the cron job has gone wrong.
The most likely cause is trying to include files relative to the root folder as the root is different when run as a cron to what it is when run in the browser.
I did as you suggested, that is added MAILTO=you@example.com to top of the Cron Tab page and removed -dump > /dev/null from the program that is not being executed, but this morning the program that is not being executed was not executed again and I received NO emails as per this program not being executed!
There is another set to run Wed morning. That was not executed either. So these 2 same programs, but ran with different parameters are the only 2 that are not getting executed by Cron!
Could it be that Cron will not run same program in 2 different days, even if they have different parameters? I cannot imagine for the life of me why this would be the case. but starting to see that that maybe the case! Have you heard of such a thing?
That will first echo “Test” (which will be sent to you by email) and then execute the program. So if that works you can be sure that at least the command is being run but doesn’t execute correctly.
Oh, and I am assuming that email is set up correctly on your system. Of course if it isn’t, none if this will work.
Not sure why you also removed the -dump there. All you needed to remove was > /dev/null
Needless to say, you don’t have to wait for next Tuesday of course, you can just change the parameters of cron to make it run earlier.
Ok, after some work I was finally able to get the Cron to send me a message when the program it is trying to execute did not execute. And what I am getting is really strange, since the Cron is reporting that:
This page does not exist on AnooX any
longer. It may have been moved or expired. * Donate
Go to Home Page
When this file does exist, since I just copy & pasted that URL into my Web browser and manually ran it. So the same URL that the Cron is saying does not exist it does EXIST since I can manually run that same URL.
What the HEK is going on?
Also, FYI: there are many other programs in that Cron page with the same URL base and they are being executed OK, but just not this one!
Thanks for your insight into this STRANGE STRANGE problem!
When you uploaded the file there was an existing one there that got over-written?
AFAIK CRON goes by the filesystem path, not the HTTP request path. So if there is any symlink or htaccess rewrite hokey-pokery going on that might be in play here.
