PHP at 7.3.23, but getting an error message to update PHP

Hi there,

same issue here since the last MAtomo update to V.4

I was using Php 7.3.xx
and I updated to 7.4, I still have the same Cron Issue from Plesk :

Error in Matomo: To run Matomo you need at least PHP version 7.2.5 Unfortunately it seems your webserver is using PHP version 7.0.33-0ubuntu0.16.04.16. Please try to update your PHP version, Matomo is really worth it! Nowadays most web hosts support PHP 7.2.5.

I checked my Php version from the server, I put also a phpinfo in MAtomo folder, I have the right php Version (7.4)

I removed and re dreated my cron task, same issue.
I updated Matomo to the latest version 4.05

In my Matomo admin account I can read :slight_smile:

Matomo version : 4.0.5
MySQL version : 10.1.48-MariaDB-1~xenial
PHP version : 7.4.13

Defintely I think this issue is coming from the last update.
Something goes wrong in some updated files of Matomo.

So … I’m waiting for an update ?

Thank you for your help.

Philippe.

Hi,

Interestingly you have the exact oposite issue as @arnego2. In your case the webserver properly uses the correct PHP version (as you confirmed with the phpinfo file) and therefore the Matomo UI should be working fine.

But the cronjob is failing due to that error and this is because php-cli is completly separate. So you need to check your crontab and see which php binary you use to call /console and check if it is also PHP 7.4

Hi Lukas,

before te Matomo Update to v4.0 I was using the same Cron task, on same server with same binary.
I changed nothing.
So you mean before V4.0 the cron task could use a PHP version equal to 7.0.33 ?
Because I dont know where I can check this Php-cli version ?

Hi,

Matomo 3 supported PHP 5.6+, so you wouldn’t have noticed if the archiving was using the “wrong” PHP version.

Check your crontab. For me the command looks like this

0 * * * * www-data /usr/bin/php7.3 /var/www/matomo/console core:archive

Depending on your server setup and operating system this might look different, but nevertheless it should specify which program executes the command.

Ok, thanks Lukas,

my Cron is completely different :

/usr/bin/php /var/www/vhosts/mywebsite.xyz/httpdocs/matomo/console core:archive --url=https://mywebsite.xyz/matomo/ > /dev/null

I will try your version and let you know.

My version will not work as is on your system

Check which PHP version /usr/bin/php is (e.g. via /usr/bin/php --version)

You’re right !
In my folder /usr/bin/ I have only php7.0
So I need to upload the 7.4 binary file.

So far I’m in the first week to search, anyone with an idea for the location?

Ok it worked

I duplicated the php file php7 from the folder /opt/plesk/php/7.4/bin/php in folder
I renamed it as php7.4 and moved it to /usr/bin/

My cron is finally :
/usr/bin/php7.4 /var/www/vhosts/mywebsite.xyz/httpdocs/matomo/console core:archive --url=https://mywebsite.xyz/matomo/ > /dev/null

Thanks for your support.

Philippe.

Hi Arne,

take a look over here :

1 Like

Done that, no changes.
outputs:

php -i |grep php.ini
Configuration File (php.ini) Path => /etc/php/7.4/cli
Loaded Configuration File => /etc/php/7.4/cli/php.ini


php --ini
Configuration File (php.ini) Path: /etc/php/7.4/cli
Loaded Configuration File: /etc/php/7.4/cli/php.ini
Scan for additional .ini files in: /etc/php/7.4/cli/conf.d
Additional .ini files parsed: /etc/php/7.4/cli/conf.d/10-mysqlnd.ini,
/etc/php/7.4/cli/conf.d/10-opcache.ini,
/etc/php/7.4/cli/conf.d/10-pdo.ini,
/etc/php/7.4/cli/conf.d/15-xml.ini,
/etc/php/7.4/cli/conf.d/20-bcmath.ini,
/etc/php/7.4/cli/conf.d/20-bz2.ini,
/etc/php/7.4/cli/conf.d/20-calendar.ini,
/etc/php/7.4/cli/conf.d/20-ctype.ini,
/etc/php/7.4/cli/conf.d/20-curl.ini,
/etc/php/7.4/cli/conf.d/20-dom.ini,
/etc/php/7.4/cli/conf.d/20-exif.ini,
/etc/php/7.4/cli/conf.d/20-ffi.ini,
/etc/php/7.4/cli/conf.d/20-fileinfo.ini,
/etc/php/7.4/cli/conf.d/20-ftp.ini,
/etc/php/7.4/cli/conf.d/20-gd.ini,
/etc/php/7.4/cli/conf.d/20-gettext.ini,
/etc/php/7.4/cli/conf.d/20-iconv.ini,
/etc/php/7.4/cli/conf.d/20-intl.ini,
/etc/php/7.4/cli/conf.d/20-json.ini,
/etc/php/7.4/cli/conf.d/20-mbstring.ini,
/etc/php/7.4/cli/conf.d/20-mysqli.ini,
/etc/php/7.4/cli/conf.d/20-pdo_mysql.ini,
/etc/php/7.4/cli/conf.d/20-phar.ini,
/etc/php/7.4/cli/conf.d/20-posix.ini,
/etc/php/7.4/cli/conf.d/20-readline.ini,
/etc/php/7.4/cli/conf.d/20-shmop.ini,
/etc/php/7.4/cli/conf.d/20-simplexml.ini,
/etc/php/7.4/cli/conf.d/20-sockets.ini,
/etc/php/7.4/cli/conf.d/20-sysvmsg.ini,
/etc/php/7.4/cli/conf.d/20-sysvsem.ini,
/etc/php/7.4/cli/conf.d/20-sysvshm.ini,
/etc/php/7.4/cli/conf.d/20-tokenizer.ini,
/etc/php/7.4/cli/conf.d/20-xmlreader.ini,
/etc/php/7.4/cli/conf.d/20-xmlwriter.ini,
/etc/php/7.4/cli/conf.d/20-xsl.ini,
/etc/php/7.4/cli/conf.d/20-zip.ini

All system runs on 7.4 so far I can see

No, the PHP binary you invoke with php on the command line runs on 7.4. This says nothing about what your web server uses?

hm thx, how are the chances that you have that comandline at hand?

For that you need to check your apache config (or create a phpinfo file in the Matomo dir to check)

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@xxxxxxd:~# php -i
phpinfo()
PHP Version => 7.4.13

System => Linux xxxxxxx 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 (2018-04-29) x86_64
Build Date => Nov 30 2020 20:40:50
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php/7.4/cli
Loaded Configuration File => /etc/php/7.4/cli/php.ini
Scan this dir for additional .ini files => /etc/php/7.4/cli/conf.d
Additional .ini files parsed => /etc/php/7.4/cli/conf.d/10-mysqlnd.ini,

Hi,

Entering phpinfo() into the commandline-php only shows you the information about the commandline-php.

You need to put this in a valid PHP file (e.g. test.php with the following content:

<?php
phpinfo()

and then access it from the browser.

The output of

<?php phpinfo()

has not changed its still at as I ignore where is the info fetched from

Hi all
the solution is here

basically this did the trick:
> sudo update-alternatives --set php /usr/bin/php7.4
> # sudo update-alternatives --set phar /usr/bin/phar7.4
> # sudo update-alternatives --set phar.phar /usr/bin/phar.phar7.4
> # sudo update-alternatives --set phpize /usr/bin/phpize7.4
> # sudo update-alternatives --set php-config /usr/bin/php-config7.4

now I’m looking into the timeout error

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

How about the matomo tecs responsible for Updates test before shipping out the updates?

1 Like

Hi,

This error comes from your MySQL server and you might want to look into this:
https://matomo.org/faq/troubleshooting/faq_183/

1 Like

Hi Lukas
Nope it came from using my native IP which is blocked due to sanctions. Kinda anticipated obedience. I went past that, using VPN and at the moment I’m updating the DB.

Wish me luck :slight_smile:

1 Like