I'm running a script in cron that sends email using smtp and a socket, and it was working until I upgraded OS, WHM, and cPanel about a month ago. Now it doesn't send email (run from cron) and doesn't cause an error in any log (cron, PHP, Apache). It seems to be run under the correct user and in the correct working dir. I'm stumped. It works when run directly in the browser address bar, either locally or remotely, but not under cron.
I do not know where the crontab command is in my system. I provide the command "php -f /home/nsr/public_html/mon-m3maje.php" using cPanel. I am not expert with Linux, although I've learned a lot about it and WHM and cPanel. I am a Windows programmer since 1994.
You may get some help from this thread:
CLI not recognized in cron jobs
and the docs page might also be helpful:
Cron Jobs - Version 68 Documentation - cPanel Documentation
CLI not recognized in cron jobs
and the docs page might also be helpful:
Cron Jobs - Version 68 Documentation - cPanel Documentation
No, I see no help there. The command "php -f PATH" should work, and did work before the upgrade. There seem to be some new bugs in cron that have not yet been fixed. But I am not sure if they are the cause of the problem I am describing here. I am investigating further by instrumenting my php program.
Following your updates, you may need to be calling the absolute path for whatever php binary you use for that domain.
If you let us know what EasyApache you use, and which PHP handler and version, and which cPanel you have installed, we might be able to make an educated guess at what your cron command should be.
You have marked yourself as a Reseller Owner - you probably want to ask whoever you get your reseller package from; what the path to the php binary you use on that domain should be.
If you let us know what EasyApache you use, and which PHP handler and version, and which cPanel you have installed, we might be able to make an educated guess at what your cron command should be.
You have marked yourself as a Reseller Owner - you probably want to ask whoever you get your reseller package from; what the path to the php binary you use on that domain should be.
Last edited:
No documentation says that php -f PATH no longer works. That makes no sense. It should use the default version of PHP. The installed WHM documentation says that both the default and specific version commands work.
See known EasyApache bug list at Current Status of EasyApache 4 - EasyApache 4 - cPanel Documentation
See also bug report at CLI not recognized in cron jobs
I plan on instrumenting my test case to learn more. Please standby with suggestions until I have more information, thanks.
See known EasyApache bug list at Current Status of EasyApache 4 - EasyApache 4 - cPanel Documentation
See also bug report at CLI not recognized in cron jobs
I plan on instrumenting my test case to learn more. Please standby with suggestions until I have more information, thanks.
As a long-time software engineer, I reserve the right to insult without realizing, and in general not understanding tact.
Hello,
Have you reported this issue to your reseller hosting provider so they can take a closer look and verify if they've made any changes to the PHP configuration or handler on the system? Note you should follow the PHP command example referenced in the following post when setting up cron jobs:
CLI not recognized in cron jobs
Thank you.
Have you reported this issue to your reseller hosting provider so they can take a closer look and verify if they've made any changes to the PHP configuration or handler on the system? Note you should follow the PHP command example referenced in the following post when setting up cron jobs:
CLI not recognized in cron jobs
Thank you.
Cron should be able to execute standard commands like "php -f PATHNAME" and not require that a particular version of PHP should be specified.
Indeed, when I found the problem the cron job is now working again.
The problem was the same in all three versions of PHP: the allow_url_fopen directive in the php.ini file, which is supposed to be enabled by default, was disabled (as seen in the WHM multi php editor). This caused a "file_get_contents" function in my programs to return NULL or an empty string, which in turn made the program skip the part where it sends email.
Here is a short test program anyone can use to detect the problem:
This test program still fails when run in a browser: "removed/test.php" . But my cron job is once again sending me appropriate emails.
Thank you all for being patient while I figured this out.
Indeed, when I found the problem the cron job is now working again.
The problem was the same in all three versions of PHP: the allow_url_fopen directive in the php.ini file, which is supposed to be enabled by default, was disabled (as seen in the WHM multi php editor). This caused a "file_get_contents" function in my programs to return NULL or an empty string, which in turn made the program skip the part where it sends email.
Here is a short test program anyone can use to detect the problem:
Code:
<?php
$URL="http://removed";
[email protected]_get_contents($URL);
echo "Contents of $URL as read by file_get_contents:<br>";
echo $Contents;
echo "<br>";
?>Thank you all for being patient while I figured this out.
Last edited by a moderator:
After a graceful reboot of my server, the test program t.php seems to run correctly in a browser.
Consider this thread closed, with a possible WHM bug discovered.
Consider this thread closed, with a possible WHM bug discovered.
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
| S | Cron Job on Hostgator | 1 | ||
| C | spamassassin sa-learn run on cron job | 10 | ||
| J | Create a Delete Email Cron Job? | 5 | ||
| D | Anacron job 'cron.daily' - freshclam.log | 2 | ||
| E | Cron job email flagged as phishing | 6 |