Troubleshooting 🕒 cron job issues on cPanel

Check if Cronjob is properly created

The first thing that we need to check when troubleshooting issues with corn jobs on cpanel is if the corn job is properly created. For this we go to cPanel > Cron Jobs

Make sure that the cronjob is listed on this page, that the format is okay and that scripts use absolute paths:

Example:

absolute paths for php that can be used in cron jobs:

• /usr/local/bin/php
• /usr/local/cpanel/3rdparty/bin/php
• /usr/local/cpanel/3rdparty/php/73/bin/
• /opt/cloudlinux/alt-php73/root/usr/bin/php
• /opt/cpanel/ea-php73/root/usr/bin/php

Check if cron job is running

After making sure that the cron job is properly added in cpanel, we can check if it is triggered when scheduled:

Afterward we can check the Apache error log if there were any errors when the cron was triggered:

tail -2000 /var/log/apache2/error_log | grep cpanelusername

If everything went smooth, you will only see INFO messages in the log.

If there is no errors in both logs, but the client is still getting emails that cron failed, then its probably a problem with the script itself or the service that is being used.

In this particular case it was cpupdate to blame, which restarted MySQL service at the same time when the cron was scheduled, which resulted with the following error:

Connection failed: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

we can confirm this by checking mariadb service status and it states that it was indeed restarted at this exact time:

Test the command from the CMD

Never run user’s PHP script from the terminal with the root account because this can lead to security problems such as user permissions escalation

If the cron job itself is properly added and from the logs you can clearly see that it was indeed executed, but the client is claiming the cron is not working nor that there is a problem with the script itself, then we can try to replicate the problem from the terminal.

To stitch from root to cpanel user, run:

su -l cpanelusername

If the users cpanel package doesn’t have terminal access enabled in features, we will receive the following error message:

We can work around this by specifying which shell to use:

1su -l -s /usr/local/cpanel/bin/jailshell cpanelusername

you can check which shell is being used for cronjobs in the cron file itself:

crontab -e

Most common issues with cron job in cPanel:

Wrong PHP version that is missing the required extension

When running PHP scripts from the terminal, clients motly use the following path for PHP: /usr/local/bin/php , which means that the script is being run by the default PHP version which is not always the same as the one that the website itself is running on.

For more information about this, check this great Q&A page from cPanel: PHP CGI vs PHP CLI What’s the difference? & How to use them

If the client wants to run the script using a specific PHP version, then they need to use the full path to that PHP version:

For EasyApache “ea” variant of PHP, use the following path but make sure you replace XX with the version number:

/opt/cpanel/ea-phpXX/root/usr/bin/php

 For CloudLinux “alt” variant of PHP, use the following path but make sure you replace XX with the version number:

/opt/cloudlinux/alt-phpXX/root/usr/bin/php

Missing User-Agent string in wget – curl commands

If the cron job itself uses wget, make sure that you test this command from the terminal:

wget https://pcx3.com/awesom-file.zip

Instead of using wget command we can use both lynx or curl, but keep in mind that these days most shared hosting providers use COMODO WAF’s mod_security rules which in the latest PHP update are blocking access to this commands without a valid user agent.

Example curl command with an user agent:

/usr/bin/curl --user-agent cPanel-Cron https://pcx3.com/awesom-file.zip

• curl –user-agent YOUR_STRING (URL)
• lynx -dump -useragent=YOUR_STRING (URL)