Errors with cronjobs after fresh install

Hi guys, thankful for any help:

Your software
Mautic 3.1.1 (newly installed it myself from mautic.org)
MySQL 8.0.19
php 7.4.10

Your problem
Cronjobs produce errors:
Running cronjobs
/[redacted]/php /home/www/mautic/bin/console mautic:segments:update >>/[redacted]/logs/mautic-segments-update.log 2>&1
/[redacted]/php /home/www/mautic/bin/console mautic:campaigns:update >>/[redacted]/logs/mautic-campaigns-update.log 2>&1
/[redacted]/php /home/www/mautic/bin/console mautic:campaigns:trigger >>/[redacted]/logs/mautic-campaigns-trigger.log 2>&1

Each one repeatedly yield following log output:
PHP Warning: Class ‘Tightenco\Collect\Support\LazyCollection’ not found in /[redacted]/mautic/vendor/tightenco/collect/src/Collect/Support/alias.php on line 19
PHP Parse error: syntax error, unexpected ‘=’ in /[redacted]/mautic/vendor/tightenco/collect/src/Collect/Support/LazyCollection.php on line 611

I am aware that there are two threads dealing with the same output message:

However, the solution was to 1) upgrade MySQL version, and to 2) upgrade a php version. For both I already had been using higher versions

What I tried

  • Downgrading php to 7.3 or 7.2 → No change, warnings/errors persist
  • Manually runing cronjobs via ssh yield same output

Any help is deeply appreciated

Its my understanding that php 7.4 is not supported currently with any version of mautic, but it is on the way.

Have you set php 7.3 and cleared your cache via /bin/console cache:clear -vvv ?
Php version incompatibility may be causing the syntax error.

Thanks @EJL for taking the time, appreciate it.

I changed php to 7.3.22, restarted Apache and via ssh I issued
/[…]/bin/php /[…]mautic/bin/console cache:clear -vvv

Interestingly, I get the exact same error messages in PuTTY, even when doing a /bin/console --?

PHP Warning: Class ‘Tightenco\Collect\Support\LazyCollection’ not found in /[…]/mautic/vendor/tightenco/collect/src/Collect/Support/alias.php on line 19
PHP Parse error: syntax error, unexpected ‘=’ in /[…]/mautic/vendor/tightenco/collect/src/Collect/Support/LazyCollection.php on line 611

Is there some other way to manually clear the cache? Or can you point me to some docs? Sorry, I am not realy an ssh cli artists here.

Ok, found the part how to clear the cache. Manually deleted all files in var/cache.
Still no change, same error messages.

Is this a clean vps or you are using some sort of control panel?

If it won’t hurt, I’ll suggest deploying another instance of Clean VPS, and this time, make sure you are using php 7.3.

if you can’t redeploy a new one or you are using a control panel, try to locate the path where your php is installed (type which php in the console to see the path), if you found it, test run in the shell using the full php path, e.g

/path/to/php /path/to/mautic/bin/console/blah blah blah

If that doesn’t work and you are using Ubuntu or Debian, try to see the php version installed on your system using:

apt list --installed | grep php

If you find a different php version e.g php7.4, remove it using

apt remove php7.4

or purge your php packages all together using

apt purge php*

Reinstall php 7.3 or 7.2 again, and retry.

1 Like

Thanks for your help.

I am actually on a shared server, but I do have my own exclusive apache running on it. Still, I do set php version via GUI.

Requirements are satisfied. In the first step of the installation - when routine checks for missing components in the environment - nothing is reported, I just get the green ok.

I now deleted and reinstalled mautic (including entire MySQL db) under php 7.3.22.
Interestingly, still no change. When I manually run the tasks for cronjobs via ssh I get the very same error as before.

Maybe it has something to do with php configuration?
This is what i see from php.ini (some are my additions):

mysqli.default_socket = /var/run/mysqld/mysqld.sock
mysql.default_socket = /var/run/mysqld/mysqld.sock
pdo_mysql.default_socket = /var/run/mysqld/mysqld.sock
pdo_mysqli.default_socket = /var/run/mysqld/mysqld.sock
mysql.allow_persistent = Off
mysqli.allow_persistent = Off
curl.cainfo = /etc/ssl/certs/ca-certificates.crt
upload_max_filesize = 150M
post_max_size = 150M
display_errors = Off
session.save_path = /tmp
error_reporting = E_ALL & ~E_NOTICE
date.timezone = ‘Europe/Berlin’
expose_php = Off
[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_[php].so
memory_limit = 512M
zend_extension=opcache.so
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

does the correct php version display when you run php-v?

It should give output like this

PHP 7.3.23 (cli) (built: Sep 29 2020 08:33:03) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.3.23, Copyright © 1998-2018 Zend Technologies
with the ionCube PHP Loader + ionCube24 v10.4.4, Copyright © 2002-2020, by ionCube Ltd.
with Zend OPcache v7.3.23, Copyright © 1999-2018, by Zend Technologies

1 Like

Solved it. @EJL, You brought me on the right track:

While phpinfo() outputs php7.3 as I expected, running php -v on the CLI revealed that SSH and cron jobs are actually running with php 7.0.

So I had to learn that setting the php version in hoster’s GUI (some homebrew, not cPanels) does only affect the version my apache is using. CRONs and ssh were always running with php 7.0, independent of any GUI settings. Mind that. Hence the errors.

After talking to the hoster they gave me access to the 3.7 files, which I call now in the cron with a fully qualified path. Working like a charm now.

Thanks guys, simple solution but it needed your input to grasp whats going on.

1 Like