How to troubleshoot user level cron issues

Introduction

You may use the following information to troubleshoot problems with cronjobs run by cPanel users.

Use absolute paths for all binaries, both in cron, and when testing via CLI

When not using the absolute path to a binary, it is possible that a different binary will be used when the cron is run vs when testing via CLI. This makes troubleshooting difficult or impossible.

Specifically, if you use "php" as the command, the CLI version of the binary is used when testing via CLI but the CGI version of the binary is used when run via cron.

Here are some recommended full paths to use when both troubleshooting via CLI, and for use in the cron command:

Use the absolute path to the script being run

It is possible to use a relative path to the script that you are executing via cron and CLI. For example:

Cron:

* * * * *  /usr/local/bin/php example.php

CLI:

/usr/local/bin/php example.php

CLI version 2:

./example.php

Using a relative path as seen above introduces additional complexity when troubleshooting problems. 

You will avoid wasting a lot of time if you use the full path to your script both in cron and on the CLI when testing.

You can find the full path of your script with the following steps:

1. Access the CLI via SSH or the Terminal icon in cPanel or WHM

2. Use the cd command to navigate to the location of your script

3. Use the pwd command to show the current directory that your script is in

4. Combine the path provided by the pwd command and the script name to create the absolute path

The end result should look something like this:

Cron:

* * * * *  /usr/local/bin/php /home/cpanelusername/public_html/path/to/script/example.php

CLI:

/usr/local/bin/php /home/cpanelusername/public_html/path/to/script/example.php

Reproducing the problem via the CLI

First login to the CLI via SSH or Terminal as the cPanel user.

If you are logged into the CLI as the root user, you can use the following command. The -l flag is very important because it recreates the user's environment:

su -l cpanelusername

It is possible that you may see the following error when attempting to switch to the cPanel user:

Shell access is not enabled on your account!
If you need shell access please contact support.

You can bypass this error by manually specifying the shell to use:

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

Once you have logged in as the cPanel user, you may list the existing crons with the following command:

crontab -l

To reproduce the error, run the command that you find in the crontab. Please note that if the cron is using relative paths, you should first change the cron so that it uses absolute paths as is noted in the earlier sections of this guide.

You can edit the cron with the following command:

crontab -e

Failed opening required '../../example.php' errors

Some scripts make use of relative paths. Those relative paths are based on the current working directory. In order to resolve issues with resolving the location of relative paths, you must use the cd command to update the current working directory to that of the script that you are running in the cron. For example:

* * * * * cd /path/to/script; /usr/local/bin/php /path/to/script/example.php

Permissions errors

If you get permissions errors when running the cron command, check the permissions with the stat command and verify that they are correct:

stat /home/cpaneluser/path/to/script.php

Using a bare file path to a script can introduce permissions related problems if it is not marked executable:

* * * * * /home/cpaneluser/path/to/script.php

Instead, it is advisable to use an absolute path to the interpreter in front of the absolute path to the script to avoid permissions errors and other problems:

* * * * * /usr/local/bin/php /home/cpaneluser/path/to/script.php

Another potential issue is the script might not be owned by your cPanel user. Use the chown command via CLI to fix the ownership:

chown cpaneluser:cpaneluser /home/cpaneluser/path/to/script.php