3

I updated to 5.39.0 on Friday, and upon logging in today I've discovered that cron doesn't seem to have run since. I've checked my host's cronlog, and it reports that the command has been sent, so I've logged in and tried it manually from the command line which initially returned this error:

bash-4.2$ /usr/bin/php-7.3 /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm/bin/cli.php -s beta.example.net -u username -p password -e Job -a execute    
Warning: require_once(/var/sites/e/example.net/public_html/sites/all/modules/civicrm/CRM/Core/ClassLoader.php): failed to open stream: No such file or directory in /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm/civicrm.config.php on line 138

I've had problems before that I think are related to this - when I first created the site I was testing on beta.example.net and then moved it over to example.net when it was fully functioning, but the host won't let us change the primary account name. I've found that CiviCRM only loads when $civicrm_root in civicrm.settings.php is set as /var/sites/e/example.net/public_html/sites/all/modules/civicrm, but command line tools like drush will only work if $civicrm_root is /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm.

So it looks like something has changed in 5.39.0 that means something in civicrm.config.php is now using the $civicrm_root path where it wasn't before? And as the cronjob is run from the command line that's causing it to fail?

Obviously, before too long I need to find a work around for this. I can't switch the path over every fifteen minutes for the cronjob to run. In the meantime though, I've carried on trying to force it from the command line with the path set such that it should run, and even that's not working. I'm now getting this error:

bash-4.2$ /usr/bin/php-7.3 /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm/bin/cli.php -s beta.example.net -u username -p password -e Job -a execute
TypeError: Argument 2 passed to CRM_Contact_BAO_GroupContactCache::getGroupsNeedingRefreshing() must be of the type int, string given, called in /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm/CRM/Contact/BAO/GroupContactCache.php on line 132 in CRM_Contact_BAO_GroupContactCache::getGroupsNeedingRefreshing() (line 715 of /var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm/CRM/Contact/BAO/GroupContactCache.php).

As far as I know, everything was running fine prior to 5.39.0. Any suggestions?

1

1 Answer 1

6

I would upvote @Demerit if his comment was an answer, but instead I posted some additional info at the link they gave. To satisfy Stack Exchange guidelines, I'll post it below:

  • In Administer menu » System Settings » Scheduled Jobs, edit the Rebuild Smart Group Cache settings to read limit=0 instead of limit=Number optional-Limit the number of smart groups rebuild.
  • You may want to read this documentation about optimizations, particularly the part about whether you want Rebuild Smart Group Cache enabled at all.
2
  • Thanks for this, that fixed my problem too. One question - will this disable the smart groups from updating now? Or do I have to wait for the next version of CiviCRM before changing the option back to the default?
    – Vshura
    Commented Jul 28, 2021 at 9:49
  • 1
    @Vshura The smart groups will update. Note however that they were NOT updating before, so you may run into errors if you have an inefficient smart group. Most smart groups take under 1 second to calculate, if you have one that takes many minutes, it can cause the rest of your cron job not to complete. Commented Jul 28, 2021 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.