Question

Issues with CRON job executing on Ubuntu 20.04 with PHP 7.4 FPM

Posted October 2, 2021 110 views
PHPLinux CommandsUbuntu 20.04

I am having issues properly setting up the following CRON job to automate backups on my client’s website.

The site is Joomla-based and I am using Akeeba Backup to handle the backups. The recommendations for the command-line CRON jobs are as follows:

Use the following command in your host’s CRON interface: /path/to/php /var/www/domain.com/cli/akeeba-backup.php

Remember to substitute /path/to/php with the real path to your host’s PHP CLI (Command Line Interface) executable. Do remember that you must use the PHP CLI executable; the PHP CGI (Common Gateway Interface) executable will not work with our CRON scripts. If unsure what this means, please consult your host. They are the only people who can provide this information.

domain.com used as an example

I have CRON installed and running on Ubuntu 20.04.

The following code is in crontab -e

0 3 * * * /usr/bin/php7.4 /var/www/domain.com/cli/akeeba-backup.php --profile=1 --description="Full automated backup"

The site is running PHP 7.4 with FPM installed.

When I run which php the following is returned: /usr/bin/php

When I run ls -l /usr/bin/php the following is returned: lrwxrwxrwx 1 root root 21 Aug 31 18:09 /usr/bin/php -> /etc/alternatives/php

When I run ls -l /etc/alternatives/php the following is returned: lrwxrwxrwx 1 root root 15 Aug 31 18:53 /etc/alternatives/php -> /usr/bin/php8.0

As this shows version 8.0 instead of 7.4, which the site is using, does this mean the CRON job should be using version 8 instead.

Sample log output from /var/log/syslog

Oct 1 11:39:01 domain CRON[38538]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)

Any help is greatly appreciated.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

Hello,

As the website uses PHP 7.4, I believe that it is best to run the cronjob with PHP 7.4 as well for consistency.

To check if this /usr/bin/php7.4 is the correct path to the PHP 7.4 executable, you could run the following command:

/usr/bin/php7.4 -v

If the output indicates that the PHP version is 7.4, then I could suggest running the command manually:

/usr/bin/php7.4 /var/www/domain.com/cli/akeeba-backup.php --profile=1 --description="Full automated backup"

That way you will be able to see if there are any errors when the command is executed.

If you get any errors feel free to share them here after removing any sensitive information from the output.

Regards,
Bobby

  • Hello Bobby,

    Thanks for the reply and the help.

    Here is the results of /usr/bin/php7.4 -v: PHP 7.4.24 (cli) (built: Sep 23 2021 21:36:11) ( NTS )

    When I run /usr/bin/php7.4 /var/www/domain.com/cli/akeeba-backup.php --profile=1 --description="Full automated backup", the following output is returned.

    Backup output directory /var/www/domain.com//administrator/components/com_akeeba/backup needs to be both readable and writeable to PHP for this backup software to function correctly.
    
    Technical information:
    
    Code: 0
    File: /var/www/domain.com/administrator/components/com_akeeba/BackupEngine/Util/FactoryStorage.php
    Line: 49
    
    Stack Trace:
    
    #0 /var/www/domain.com/administrator/components/com_akeeba/BackupEngine/Util/FactoryStorage.php(68): Akeeba\Engine\Util\FactoryStorage->get_storage_filename()
    #1 /var/www/domain.com/administrator/components/com_akeeba/Model/Backup.php(130): Akeeba\Engine\Util\FactoryStorage->reset()
    #2 /var/www/domain.com/cli/akeeba-backup.php(274): Akeeba\Backup\Admin\Model\Backup->startBackup()
    #3 /var/www/domain.com/libraries/src/Application/CliApplication.php(143): AkeebaBackupCLI->doExecute()
    #4 /var/www/domain.com/cli/akeeba-backup.php(470): Joomla\CMS\Application\CliApplication->execute()
    #5 {main}
    

    The permissions for the defined directory are 755 with owner and group set to www-data.

    The odd thing is the output directory for the backups should be one level above the domain.com directory, but the app is not using for it some reason. This directory’s permissions are also set to 755 with the owner and group set to www-data.

    I am assuming this is an issue with the app, but would like to confirm that my server and PHP CLI settings are correct before approaching the developer of Akeeba.

    Thanks again for your assistance.

    Cheers,

    • Hi there,

      Indeed this could also indicate that the directory path is not correct. What I could suggest is running the following command:

      ls -lah /var/www/domain.com//administrator/components/com_akeeba/ | grep backup
      

      That way you would see if the backup directory that the script is trying to use exists.

      Also, what user are you using to run the PHP command and corn job as? If you are not using the www-data user, then you might have to change the permissions to 777 or change the group of the backup directory to the user that you are using and set the permissions to 775.

      Let me know how it goes.

      Best,
      Bobby

      • Hello Bobby,

        Thanks for the reply.

        The directory does exist. PHP is being run under the user I setup while provisioning the server.

        I did change the group for the backup directory to the user I setup and set the permissions to 775. This seems to have solved the issue as the /usr/bin/php7.4 /var/www/domain.com/cli/akeeba-backup.php --profile=1 --description="Full automated backup" command successfully worked.

        I also applied the changes to the directory outside of the root and it seems to be working correctly there too.

        Are there any security issues with setting the permissions and group ownership like this for backup directory?

        Cheers,

        • Hello,

          Happy to hear that it is working after the change! This should be Ok as only your user is part of that group so any other users besides the www-data user and your user would not be able to write to the directory.

          Best,
          Bobby