Resolved Cron job won't run in DirectAdmin

[cardboa7]

I have a single cron job for my free x10hosting account. It is set to run every (6) minutes. ("*/6" is the in the "Minute" column; the other 4 time-period columns contain an asterisk.)

The most recent instance that the cron job ran was on December 26, 2019, which was of course the date that admins transitioned free accounts from cPanel to DirectAdmin.

In DirectAdmin's "Profile Setup" -> "Account Configuration", the "Cron Jobs" setting is Enabled.

Here is the original command that worked great up until that point:

• /usr/bin/php -f /home/[USERNAME]/public_html/[PHP FILENAME].php >/dev/null 2>&1

I've changed this command to the following commands, but none have worked:

• /usr/bin/php -q /home/[USERNAME]/public_html/[PHP FILENAME].php >/dev/null 2>&1

• /usr/bin/php -f /home/[USERNAME]/domains/[SUBDOMAIN].x10host.com/public_html/[PHP FILENAME].php >/dev/null 2>&1

• /usr/bin/php -q /home/[USERNAME]/domains/[SUBDOMAIN].x10host.com/public_html/[PHP FILENAME].php >/dev/null 2>&1

• /usr/bin/php -q /home/[USERNAME]/domains/[SUBDOMAIN].x10host.com/public_html/[PHP FILENAME].php

I searched the forum for help and found these other users facing the same issue:

• Cron Jobs

• File path for a cronjob

• Cron Jobs post-cPanel to DirectAdmin

But, the answers provided did not solve the issue for me.



Can anyone please help with this matter? TIA.

 

[garrettroyce]

Instead of writing to /dev/null, write to a log file to see what's happening.

/usr/bin/php -q /home/......./something.php >2&1 > /home/[username]/cronlog.txt

This log will get big quickly. Once you've established it's running correctly, pipe the output to > /dev/null

Make sure that the path to your PHP file is all 0755 permissions and the file is 0644. Eg, every folder has to be 0755. If any folder is less than 0755, it could be a permissions error.

Turn on error reporting in your PHP script in case it's an error such as one caused by using PHP 7.2 (and the script has some legacy code), which is going to be the version of /usr/bin/php.

 

[cardboa7]

Ah, I found the issue. It had nothing to do with cron commands.




Here's a bit of context:

In my PHP file, the following code was responsible for writing the current timestamp to a log file:

$file = 'php_log.txt';
$theOriginalFileContents = file_get_contents($file);
file_put_contents($file, $theTimestamp . "\n\n" . $theOriginalFileContents);
​

The PHP file in question is located in my public_html folder, so based on the above relative file path for $file, the php_log.txt file that is updated on every iteration of the script is located in this folder as well.




The reason that I had thought that the cron job was not running is because the most recent timestamp found in this log file is 12/26/2019.

But, in fact, the cron job has been running, like clockwork, since 12/26/2019. Even with the original, unaltered command, no less! But, instead of writing to public_html/php_log.txt, a new php_log.txt file was created one level up in my root folder.

So, the takeaway here is that the x10hosting migration has resulted in a change of the "working directory" for cron jobs. It seems that cPanel's cron jobs were executed from the public_html folder, whereas DirectAdmin's cron jobs are executed from the root folder.




To fix the issue, I redefined $file using a fixed, absolute path instead of a relative path:

$file = realpath(dirname(__FILE__)) . '/php_log.txt';​

This modification ensures that no matter where the PHP script is called from, the log file that is edited is always the one located in the same directory as the PHP file (which, in my case, is the public_html folder).

More on __FILE__:

FILE is a constant defined by PHP as the full path to the file from which it is called. Even if the file is included, FILE will ALWAYS refer to the full path of the file itself – not the file doing the including.

So dirname( FILE ) returns the full directory path to the directory containing the file – no matter where it is included from and basename( FILE ) returns the file name itself.

source​

I had initially (i.e., reflexively) tried using the following line to generate the absolute file path to the text file:

$file = $_SERVER['DOCUMENT_ROOT'] . '/php_log.txt';​

But, the effect was no different than that of the original line. This is the reason why:

When running your PHP script through cron, it is executed in the context of the CLI instead of the web server. In the case of executing PHP from the CLI, the $_SERVER['DOCUMENT_ROOT'] is not populated correctly.

source ​

Thanks for your help, garrettroyce. If it wasn't for your suggestion to pipe the output to a log in my root folder, I would have never been hanging out in my root folder in the first place to notice the second php_log.txt file.