Answers.Body: <p>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:</p>
  <ul>
  <li>In <strong>Administer menu » System Settings » Scheduled Jobs</strong>, edit the <em>Rebuild Smart Group Cache</em> settings to read <code>limit=0</code> instead of <code>limit=Number optional-Limit the number of smart groups rebuild</code>.</li>
  <li>You may want to read this <a href="https://docs.civicrm.org/sysadmin/en/latest/setup/optimizations/#smart-group-and-acl-performance" rel="noreferrer">documentation about optimizations</a>, particularly the part about whether you want <em>Rebuild Smart Group Cache</em> enabled at all.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-28T09:49:06.810Z
Answers.Text: 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?
Answers.UserDisplayName: Vshura
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-28T16:01:13.847Z
Answers.Text: @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.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-14T04:03:56.337Z
Answers.LastActivityDate: 2021-07-14T04:03:56.337Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>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:</p>
  <pre><code>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
  </code></pre>
  <p>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 <code>/var/sites/e/example.net/public_html/sites/all/modules/civicrm</code>, but command line tools like drush will only work if $civicrm_root is <code>/var/sites/b/beta.example.net/public_html/sites/all/modules/civicrm</code>.</p>
  <p>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?</p>
  <p>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:</p>
  <pre><code>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).
  </code></pre>
  <p>As far as I know, everything was running fine prior to 5.39.0. Any suggestions?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-13T14:25:06.507Z
Comments.Text: For the second part see also https://lab.civicrm.org/dev/core/-/issues/2687
Comments.UserDisplayName: Demerit
Tags: <cron>
Title: Cron not running since updating to 5.39.0
ThreadText: # Cron not running since updating to 5.39.0
  
  (Asked by: username_0 on 2021-07-13)
  
  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?
  
  **Tags:** cron
  
  > **Comments:**
  > **username_1**: For the second part see also https://lab.civicrm.org/dev/core/-/issues/2687  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2021-07-14. Score: 6 | Accepted answer
  
  I would upvote @username_1 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](https://docs.civicrm.org/sysadmin/en/latest/setup/optimizations/#smart-group-and-acl-performance), particularly the part about whether you want *Rebuild Smart Group Cache* enabled at all.
  
  > **Comments:**
  > **username_3**: 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?  
  > **username_2**: @username_3 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.  
  
  ---
  
  