Answers.Body: <p>The main difference is what is the user that runs the command to process.</p>
  
  <p>In one case (the run it now), it's you, so likely an admin, with all the permissions in the world.</p>
  
  <p>If you do it from the cron, are you using the user as when you log in?</p>
  
  <p>It seems that the bin/cli.php way of running the cron has been broken in 4.7 and that the core team is working on it.</p>
  
  <p>You can follow the progress on the issue tracker <a href="https://issues.civicrm.org/jira/browse/CRM-17968" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-17968</a>
  X+</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-08T20:22:42.010Z
Answers.Text: Thanks, I'll look into these things. But what's confusing me is that it has been working. For years. And now stops working. Continually upgraded Linux, Joomla and CiviCRM but haven't run mailings for a couple of months so no clue as to whether any of the upgrades actually has caused the recent problems.
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-08T20:31:28.393Z
Answers.Text: The mailing/cronjob user has exactly the same permissions, and logging in as that user allows me to finish a mailing by "Run now". We use ``mail()``.
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-08T21:10:54.310Z
Answers.Text: ``phpinfo()`` from Apache says it's running exactly the PHP-version I get in a command line. Is there another aspect of 'different' than PHP version I should be looking for?
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-17T07:19:00.290Z
Answers.Text: And there is no difference in the `php.ini`'s except that the cli version don't exclude any modules and some minor differences in allowed post and upload sizes. (Which I have unified, just to be sure...)
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T09:23:33.947Z
Answers.Text: As I just mentioned in [in another comment](https://civicrm.stackexchange.com/questions/9457/mailings-are-started-but-not-sent-what-is-the-difference-between-a-scheduled-j#comment21258_9802) I'm back in this situation. And I've ensured that the same user are running the "Run now" and when I run the cronjob command from the shell on the server.
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-08T09:07:23.743Z
Answers.LastActivityDate: 2016-02-17T08:13:29.177Z
Answers.LastEditDate: 2016-02-17T08:13:29.177Z
Answers.UserDisplayName: Xavier
Answers.Body: <p>It's a bit of a wild guess, but can you try to change the "-s default" to "-s www.#domain#.#tld#"?</p>
  
  <p>The difference between manual and via cli.php is that the manual method does know the exact domain, and the cli method might not. (especially if you have some sort of multisite configuration)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-07T21:10:14.337Z
Answers.Text: That did not seem to make any difference. (Although good to know, had actually missed the URL-rewriting in mailings, nice!) I also did ``sudo -u www-data php bin/cli.php -j -s events.responsive.se/events -e Job -a process_mailing -u <user> -p <password>`` from the command line, which did not work either. Job ran as per the log, but no mailing sent.
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-07T20:10:50.660Z
Answers.LastActivityDate: 2016-02-07T20:10:50.660Z
Answers.UserDisplayName: Catorghans
Answers.Body: <p>It seems that there is a bug in CiviCRM 4.7, 4.7.1 and 4.7.2 which causes these symptoms (scheduled mailing stuck at "running" without actually sending, but will send using Execute Now). See <a href="https://civicrm.stackexchange.com/questions/9570/mailings-scheduler-fails-after-upgrade-to-4-7-1">here</a> and <a href="https://issues.civicrm.org/jira/browse/CRM-17968" rel="nofollow noreferrer">here</a>. I spent a day trying to find the problem before I came across the bug report, so hopefully this will save others some time looking for a misconfiguration of the mailer.</p>
  
  <p>Edit: The problem has been fixed in 4.7.3.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T09:21:30.010Z
Answers.Text: Although that bug has been fixed, I'm back at the exact same problem. (4.7.17) ;-(
Answers.UserDisplayName: thoni56
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-21T17:21:18.927Z
Answers.LastActivityDate: 2016-03-03T08:58:22.563Z
Answers.LastEditDate: 2017-04-13T12:53:13.167Z
Answers.UserDisplayName: Jern
Body: <p>Our scheduled mailings have stopped working. We upgraded to 4.7, but I'm not sure this has got anything to do with it. So I'll paint the picture, and the reason why I'm asking about jobs.</p>
  
  <p>Mailings that we create are started by they job scheduler as the should. I.e mailing status is changed from Pending to In Progress. But no mailings are sent out.</p>
  
  <p>However the following does sent a batch of mailings:</p>
  
  <ul>
  <li>manually running the "Mailings scheduler" job from "Administer->Scheduled jobs"</li>
  <li>calling the mailer function from a web call ("index.php&amp;option=com_civicrm&amp;task=civicrm/mailing/queue&amp;reset=1")</li>
  </ul>
  
  <p>Test mailings from mailing composer also works. So mail sending as such definitely works.</p>
  
  <p>The "Mailings scheduler" job reports no errors. And the status change of the mailing is done by the "Mailings scheduler" as it should.</p>
  
  <p>So I've been trying to figure out what is different between the two ways of running the "Mailings Scheduler" job. Why does dispatching from the job scheduler not work but running manually does, even though the scheduler says there are no problems?</p>
  
  <p>In summary, if I create and schedule a mailing, with a cronjob that runs every 5 minutes:</p>
  
  <ul>
  <li>the mailing is started correctly by the mailing job</li>
  <li>no mails are actually sent</li>
  <li>the mailing job reports OK on every invocation</li>
  <li>a manual run of the "Mailings Scheduler" job from "Scheduled Jobs" sends one batch of mails correctly</li>
  </ul>
  
  <p>It seems similar to <a href="https://civicrm.stackexchange.com/questions/4618/scheduled-mailings-dont-get-sent?rq=1">this question</a>, which has no accepted answer so far.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-07T16:33:53.077Z
Comments.Text: Can you give the exact cron command you are using? (you can make password unreadable if you use it)
Comments.UserDisplayName: Catorghans
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-07T19:13:47.890Z
Comments.Text: Should that matter if I can see that the "Mailings scheduler" job has been run by the crontab triggering it? I'll get back in a short while with the command.
Comments.UserDisplayName: thoni56
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-07T19:32:28.870Z
Comments.Text: crontab: ``cd $CIVI_ROOT; $PHP bin/cli.php -e Job -a execute -s default -u <user> -p <password>``
Comments.UserDisplayName: thoni56
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-11-19T08:48:25.037Z
Comments.Text: I am in Civi 4.7.12 / Drupal 7.51, and have the same problem : Mailing is sent by the CRON, but never ends (and is not actually sent) ;
  The journal says : *Finished execution of Send Scheduled Mailings with result: Succès (a:1:{s:9:"processed";i:0;})* I have to trigger it manually (run it now), and then it works : *Finished execution of Send Scheduled Mailings with result: Succès (a:1:{s:9:"processed";i:530;})*
Comments.UserDisplayName: Jacques-Marie Moranne
Tags: <mailing><scheduled-job>
Title: Mailings are started but not sent - What is the difference between a scheduled job and "Run it now"?
ThreadText: # Mailings are started but not sent - What is the difference between a scheduled job and "Run it now"?
  
  (Asked by: username_0 on 2016-02-07)
  
  Our scheduled mailings have stopped working. We upgraded to 4.7, but I'm not sure this has got anything to do with it. So I'll paint the picture, and the reason why I'm asking about jobs.
  
  Mailings that we create are started by they job scheduler as the should. I.e mailing status is changed from Pending to In Progress. But no mailings are sent out.
  
  However the following does sent a batch of mailings:
  
  * manually running the "Mailings scheduler" job from "Administer->Scheduled jobs"
  * calling the mailer function from a web call ("index.php&option=com\_civicrm&task=civicrm/mailing/queue&reset=1")
  
  Test mailings from mailing composer also works. So mail sending as such definitely works.
  
  The "Mailings scheduler" job reports no errors. And the status change of the mailing is done by the "Mailings scheduler" as it should.
  
  So I've been trying to figure out what is different between the two ways of running the "Mailings Scheduler" job. Why does dispatching from the job scheduler not work but running manually does, even though the scheduler says there are no problems?
  
  In summary, if I create and schedule a mailing, with a cronjob that runs every 5 minutes:
  
  * the mailing is started correctly by the mailing job
  * no mails are actually sent
  * the mailing job reports OK on every invocation
  * a manual run of the "Mailings Scheduler" job from "Scheduled Jobs" sends one batch of mails correctly
  
  It seems similar to [this question](https://civicrm.stackexchange.com/questions/4618/scheduled-mailings-dont-get-sent?rq=1), which has no accepted answer so far.
  
  **Tags:** mailing, scheduled-job
  
  > **Comments:**
  > **username_1**: Can you give the exact cron command you are using? (you can make password unreadable if you use it)  
  > **username_0**: Should that matter if I can see that the "Mailings scheduler" job has been run by the crontab triggering it? I'll get back in a short while with the command.  
  > **username_0**: crontab: ``cd $CIVI_ROOT; $PHP bin/cli.php -e Job -a execute -s default -u <user> -p <password>``  
  > **username_2**: I am in Civi 4.7.12 / Drupal 7.51, and have the same problem : Mailing is sent by the CRON, but never ends (and is not actually sent) ; The journal says : *Finished execution of Send Scheduled Mailings with result: Succès (a:1:{s:9:"processed";i:0;})* I have to trigger it manually (run it now), and then it works : *Finished execution of Send Scheduled Mailings with result: Succès (a:1:{s:9:"processed";i:530;})*  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2016-02-21. Score: 4 | Accepted answer
  
  It seems that there is a bug in CiviCRM 4.7, 4.7.1 and 4.7.2 which causes these symptoms (scheduled mailing stuck at "running" without actually sending, but will send using Execute Now). See [here](https://civicrm.stackexchange.com/questions/9570/mailings-scheduler-fails-after-upgrade-to-4-7-1) and [here](https://issues.civicrm.org/jira/browse/CRM-17968). I spent a day trying to find the problem before I came across the bug report, so hopefully this will save others some time looking for a misconfiguration of the mailer.
  
  Edit: The problem has been fixed in 4.7.3.
  
  > **Comments:**
  > **username_0**: Although that bug has been fixed, I'm back at the exact same problem. (4.7.17) ;-(  
  
  ---
  
  ### Answer by username_3 on 2016-02-08. Score: 1
  
  The main difference is what is the user that runs the command to process.
  
  In one case (the run it now), it's you, so likely an admin, with all the permissions in the world.
  
  If you do it from the cron, are you using the user as when you log in?
  
  It seems that the bin/cli.php way of running the cron has been broken in 4.7 and that the core team is working on it.
  
  You can follow the progress on the issue tracker <https://issues.civicrm.org/jira/browse/CRM-17968>
  X+
  
  > **Comments:**
  > **username_0**: Thanks, I'll look into these things. But what's confusing me is that it has been working. For years. And now stops working. Continually upgraded Linux, Joomla and CiviCRM but haven't run mailings for a couple of months so no clue as to whether any of the upgrades actually has caused the recent problems.  
  > **username_0**: The mailing/cronjob user has exactly the same permissions, and logging in as that user allows me to finish a mailing by "Run now". We use ``mail()``.  
  > **username_0**: ``phpinfo()`` from Apache says it's running exactly the PHP-version I get in a command line. Is there another aspect of 'different' than PHP version I should be looking for?  
  > **username_0**: And there is no difference in the `php.ini`'s except that the cli version don't exclude any modules and some minor differences in allowed post and upload sizes. (Which I have unified, just to be sure...)  
  > **username_0**: As I just mentioned in [in another comment](https://civicrm.stackexchange.com/questions/9457/mailings-are-started-but-not-sent-what-is-the-difference-between-a-scheduled-j#comment21258_9802) I'm back in this situation. And I've ensured that the same user are running the "Run now" and when I run the cronjob command from the shell on the server.  
  
  ---
  
  ### Answer by username_1 on 2016-02-07. Score: 0
  
  It's a bit of a wild guess, but can you try to change the "-s default" to "-s www.#domain#.#tld#"?
  
  The difference between manual and via cli.php is that the manual method does know the exact domain, and the cli method might not. (especially if you have some sort of multisite configuration)
  
  > **Comments:**
  > **username_0**: That did not seem to make any difference. (Although good to know, had actually missed the URL-rewriting in mailings, nice!) I also did ``sudo -u www-data php bin/cli.php -j -s events.responsive.se/events -e Job -a process_mailing -u <user> -p <password>`` from the command line, which did not work either. Job ran as per the log, but no mailing sent.  
  
  ---
  
  