Body: <p>After upgrading to 5.17.4 under Joomla, the next large CiviMail job did as follows:</p>
  
  <ol>
  <li>It never completed and had to be cancelled</li>
  <li>It reported zero successful deliveries, though it did report opens</li>
  <li>At the next cron cycle it resent the same emails.</li>
  <li>Some recipients never received emails.</li>
  </ol>
  
  <p>An examination of the ConfigAndLog file showed 'No database selected' errors.</p>
  
  <p>After upgrading to CiviCRM 5.18.2, the 'No database selected' errors went away, but the above issues remained.</p>
  
  <p>CiviCRM reports that the cron job has not run, and the scheduled jobs log shows it not finishing.  The cron command is:</p>
  
  <p>wget -q -t 1 'https:///administrator/components/com_civicrm/civicrm/bin/cron.php?name=&amp;pass=&amp;key=' </p>
  
  <p>We used to run php cli.php, but that stopped working after the 5.17.4 upgrade.</p>
  
  <p>Has anyone any suggestions as to what might be causing the issue?  It is difficult to troubleshoot as it means potentially flooding our contacts with emails.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-17T12:07:51.943Z
Comments.Text: I have done further investigations.   Jobs with five or fewer recipients run to completion, while jobs with six or more do not, but instead send to the same recipients with the next cron run.  Changing the mail batch size to 5 seems to solve the problem, but it means that large mail runs will take a very long time to complete.
Comments.UserDisplayName: Stephen Palmstrom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-11-18T22:20:47.897Z
Comments.Text: Did you find any further clues about the cause?  Are you using Mosaico/Flexmailer and/or Sparkpost?  I'm also seeing the mailing job not finishing.
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-11-20T11:44:56.810Z
Comments.Text: No, but it may be due to PHP setting limitations.  The problem occurs on a shared server where we don't have access to critical settings such as max_execution_time.  I have development system on my local PC which doesn't exhibit the issue.
Comments.UserDisplayName: Stephen Palmstrom
Tags: <civimail><cron>
Title: Mailing job never finishes, but restarts at next cron cycle
ThreadText: # Mailing job never finishes, but restarts at next cron cycle
  
  (Asked by: username_0 on 2019-10-16)
  
  After upgrading to 5.17.4 under Joomla, the next large CiviMail job did as follows:
  
  1. It never completed and had to be cancelled
  2. It reported zero successful deliveries, though it did report opens
  3. At the next cron cycle it resent the same emails.
  4. Some recipients never received emails.
  
  An examination of the ConfigAndLog file showed 'No database selected' errors.
  
  After upgrading to CiviCRM 5.18.2, the 'No database selected' errors went away, but the above issues remained.
  
  CiviCRM reports that the cron job has not run, and the scheduled jobs log shows it not finishing. The cron command is:
  
  wget -q -t 1 'https:///administrator/components/com\_civicrm/civicrm/bin/cron.php?name=&pass=&key='
  
  We used to run php cli.php, but that stopped working after the 5.17.4 upgrade.
  
  Has anyone any suggestions as to what might be causing the issue? It is difficult to troubleshoot as it means potentially flooding our contacts with emails.
  
  **Tags:** civimail, cron
  
  > **Comments:**
  > **username_0**: I have done further investigations.   Jobs with five or fewer recipients run to completion, while jobs with six or more do not, but instead send to the same recipients with the next cron run.  Changing the mail batch size to 5 seems to solve the problem, but it means that large mail runs will take a very long time to complete.  
  > **username_1**: Did you find any further clues about the cause?  Are you using Mosaico/Flexmailer and/or Sparkpost?  I'm also seeing the mailing job not finishing.  
  > **username_0**: No, but it may be due to PHP setting limitations.  The problem occurs on a shared server where we don't have access to critical settings such as max_execution_time.  I have development system on my local PC which doesn't exhibit the issue.  
  
  ---
  
  ## 0 answers
  
  