Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 0 down vote favorite

I have a dozen or so cron jobs running on my Ubuntu 12.04 server, and I use the Webmin interface to administer them. They all execute PHP scripts. Most I created a while back, and they all work fine.

Yesterday, I created a new one, and I tried as much as possible to copy the settings of all my working versions, but this new one won't run. I have it set to run every hour, and every hour I get an email saying only:

Could not open input file: php

I've checked to make sure the PHP script I'm trying to run is executable, and I've set the permissions to be 777. When I run the script directly in a browser, it executes fine.

Even more weird, in the Webmin interface, when I click to "save and run now", it seems to run fine, saying "no output generated", which makes sense, since it just does some operations on my MySQL database.

It only fails when the top of the hour comes around and it's the cron job executing it, not me doing anything manual.

Here is what the settings look like in the Webmin interface:

cron job that isn't working

Here is the output when I click "save and run":

script successfully running

Just for comparison, here are the settings on one of my working scripts:

working cron example

Why is this new cron job failing? How do I diagnose what is preventing it from working?

Information requested in the comments:

These are the (partial) contents of /var/spool/cron/crontabs/www-data. The command on the top works great. The command on the bottom is not working.

@hourly php /var/www/xxxxxxxxxxx/xxxxxxxxxxxx_report.php    #xxxxxxx error report
@hourly php /var/www/xxxxxxxxxx/htdocs/simuser.php #Script to simulate user actions
share|improve this question
Can you post the crontab file/entry that's being generated by Webmin? (I don't know anything about it, but it seems like this will tell you where to find it. – s.co.tt May 20 at 2:31
2  
I dont know anything about webmin but I can say one thing with cron jobs not running is usually a case of either permissions or path, since you using Ubuntu 12.04 go to terminal and type which php this will give you full path and use this path in the crontab entry. – APZ May 20 at 4:06
@s.co.tt, I've added the contents of the crontab file to the question. – Dave M G May 20 at 7:05
2  
Please never set 777 as permissions – Lucas Kauffman May 20 at 7:10
@LucasKauffman: Obviously. This is just for testing to ensure permissions are not the problem. – Dave M G May 20 at 7:17
show 2 more comments

closed as too localized by Iain, Jenny D, Ward, mdpc, Dennis Kaarsemaker Jun 5 at 17:08

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, see the FAQ.

2 Answers

up vote 0 down vote

It's possible that the php binary isn't in the PATH of the www-data user. Try using the full path - /usr/bin/php on Ubuntu (you can check by running the command which php).

Thanks Iain, I didn't see the crontab content.

share|improve this answer
Why would the first command work and the second not as the OP says if this were the problem ? – Iain May 20 at 7:18
up vote 0 down vote

I discovered, as is often the case, that ultimately I was at fault.

What happened was that one time while editing the cron tab settings, I must have accidentally selected to run the command as a different user and saved that as a cron job. And it was that different user's cron job that had a faulty command line syntax. It had php written twice.

I did not realize this additional, near duplicate, cron job also existed, as in the interface it's listed in a slightly different spot. The end result was that the whole time I was trying to debug a working cron job, while the faulty cron job was sending errors that referenced similar commands, making me think there was a problem where there wasn't. A maddening situation.

This situation might be too localized to be of help to others, or it might be the case that maybe it can stand as a reminder to check which users are responsible for what cron jobs and to watch out for near duplicates. I'll leave it to the moderators to decide if this question and answer is worth keeping or if it should be closed.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.