Answers.Body: <p>Check <strong>Administer menu > CiviMail > Mailer Settings</strong>, and see if the "Mailer Batch Limit" is set to 500.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T16:04:42.370Z
Answers.Text: Here is the direct link to the "Mailer Settings" page: <<yourdomain>>/civicrm/admin/mail?reset=1
Answers.UserDisplayName: Pamela
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T16:17:47.523Z
Answers.Text: The Batch Limit is indeed set to 500. Is it safe to set it to 0 (unlimited)? Our server's pretty beefy.
Answers.UserDisplayName: Joseph Cotten
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T02:30:50.093Z
Answers.Text: @JosephCotten - yeah, I always leave it at 0 unless the webhost/ESP is throttling e-mail.  I haven't seen a mailing over 38K e-mails, but I've had no problem up to that amount!  Though the default is 0, so I'd try to find out who set it to 500 and why.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T16:02:24.213Z
Answers.LastActivityDate: 2015-03-24T16:02:24.213Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>Sounds like a cron/scheduled tasks issue.</p>
  
  <p>CiviCRM has a scheduled tasks system to organise jobs that need running at regular intervals. This in turn requires that something pokes it into action frequently (e.g. every 15 mins). Typically on Linux this is done with the system's cron utility.</p>
  
  <p>Without CiviCRM being given chance to run its scheduled tasks, it will only ever do one batch - there's nothing to give it chance to run a second batch.</p>
  
  <p>Setting this up is detailed <a href="http://book.civicrm.org/user/current/initial-set-up/scheduled-jobs/" rel="nofollow noreferrer">in the book</a> and <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs" rel="nofollow noreferrer">on the wiki</a>.</p>
  
  <p>In brief, if you're on Linux + Drupal hosting, then you want a line like this in <code>/etc/crontab</code></p>
  
  <pre><code>*/15 * *   *   *   &lt;USER&gt;  umask 0002; /usr/bin/php /var/www/your.civi.site/sites/all/modules/civicrm/bin/cli.php -j -s &lt;example.com&gt; -u admin -p '&lt;DATABASE PASSWORD&gt;' -e Job -a execute
  </code></pre>
  
  <p>Nb. you might like to put those commands in another shell script and then just reference that so as to avoid your database password entering your syslog.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-07T20:43:22.867Z
Answers.Text: Can you explain the F in -p 'F<DATABASE PASSWORD>' ?
Answers.UserDisplayName: Joe Murray
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-08T07:35:10.303Z
Answers.Text: Yes. All passwords must begin with F. To do otherwise it's a grave security mistake. Um, no, it was a typo! I've removed it, thanks!
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T23:41:03.267Z
Answers.Text: Generally you can use crontab to list and manage crons: `crontab -l` to list for the current user, `crontab -e` to edit crontabs for the current user
Answers.UserDisplayName: gboudrias
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T16:52:54.907Z
Answers.LastActivityDate: 2018-03-08T07:33:44.477Z
Answers.LastEditDate: 2018-03-08T07:33:44.477Z
Answers.UserDisplayName: artfulrobot
Body: <p>When using Civi Mail, we have a recurring issue wherein the system stops sending emails at 500 sends. The job shows as incomplete.</p>
  
  <p>It is not a php timeout, as the hosting company (<a href="https://www.rochen.com/">https://www.rochen.com/</a>) has increased all our limits during testing, with no change.</p>
  
  <p>We can re-initiate the mail send, and it will send out the next set of 500 emails, then stop again. We have to continue manually triggering the send to get the full job completed.</p>
  
  <p>Any thoughts on the culprit?</p>
  
  <p>System info:
  CiviCRM 4.2.6
  Joomla 2.5.28
  php 5.3.29
  MySQL 5.5.42-cli</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-24T16:02:25.593Z
Comments.Text: Have you checked your cron setup? Without cron running you'll always be limited by whatever batch size you set.
Comments.UserDisplayName: artfulrobot
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T16:15:15.137Z
Comments.Text: We have. It runs as scheduled, and nothing's changed in the cron since we set up the site, yet this problem just started.
Comments.UserDisplayName: Joseph Cotten
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T18:50:44.440Z
Comments.Text: We're sending 500 per cron execution, and the cron executes every 10 minutes, which means 3,000 per hour. I don't want to risk getting blacklisted by sending out much more than that per hour.
Comments.UserDisplayName: Joseph Cotten
Tags: <civimail><joomla>
Title: How Do I Fix Mail Send Stopping at 500 Sends?
ThreadText: # How Do I Fix Mail Send Stopping at 500 Sends?
  
  (Asked by: username_0 on 2015-03-24)
  
  When using Civi Mail, we have a recurring issue wherein the system stops sending emails at 500 sends. The job shows as incomplete.
  
  It is not a php timeout, as the hosting company (<https://www.rochen.com/>) has increased all our limits during testing, with no change.
  
  We can re-initiate the mail send, and it will send out the next set of 500 emails, then stop again. We have to continue manually triggering the send to get the full job completed.
  
  Any thoughts on the culprit?
  
  System info:
  CiviCRM 4.2.6
  Joomla 2.5.28
  php 5.3.29
  MySQL 5.5.42-cli
  
  **Tags:** civimail, joomla
  
  > **Comments:**
  > **username_1**: Have you checked your cron setup? Without cron running you'll always be limited by whatever batch size you set.  
  > **username_0**: We have. It runs as scheduled, and nothing's changed in the cron since we set up the site, yet this problem just started.  
  > **username_0**: We're sending 500 per cron execution, and the cron executes every 10 minutes, which means 3,000 per hour. I don't want to risk getting blacklisted by sending out much more than that per hour.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-03-24. Score: 11
  
  Check **Administer menu > CiviMail > Mailer Settings**, and see if the "Mailer Batch Limit" is set to 500.
  
  > **Comments:**
  > **username_3**: Here is the direct link to the "Mailer Settings" page: <<yourdomain>>/civicrm/admin/mail?reset=1  
  > **username_0**: The Batch Limit is indeed set to 500. Is it safe to set it to 0 (unlimited)? Our server's pretty beefy.  
  > **username_2**: @JosephCotten - yeah, I always leave it at 0 unless the webhost/ESP is throttling e-mail.  I haven't seen a mailing over 38K e-mails, but I've had no problem up to that amount!  Though the default is 0, so I'd try to find out who set it to 500 and why.  
  
  ---
  
  ### Answer by username_1 on 2015-03-24. Score: 9
  
  Sounds like a cron/scheduled tasks issue.
  CiviCRM has a scheduled tasks system to organise jobs that need running at regular intervals. This in turn requires that something pokes it into action frequently (e.g. every 15 mins). Typically on Linux this is done with the system's cron utility.
  Without CiviCRM being given chance to run its scheduled tasks, it will only ever do one batch - there's nothing to give it chance to run a second batch.
  Setting this up is detailed in the book and on the wiki.
  In brief, if you're on Linux + Drupal hosting, then you want a line like this in /etc/crontab
  */15 * *   *   *     umask 0002; /usr/bin/php /var/www/your.civi.site/sites/all/modules/civicrm/bin/cli.php -j -s  -u admin -p '' -e Job -a execute
  
  Nb. you might like to put those commands in another shell script and then just reference that so as to avoid your database password entering your syslog.
  
  > **Comments:**
  > **username_5**: Generally you can use crontab to list and manage crons: `crontab -l` to list for the current user, `crontab -e` to edit crontabs for the current user  
  > **username_4**: Can you explain the F in -p 'F<DATABASE PASSWORD>' ?  
  > **username_1**: Yes. All passwords must begin with F. To do otherwise it's a grave security mistake. Um, no, it was a typo! I've removed it, thanks!  
  
  ---
  
  