3

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, which has no accepted answer so far.

Improve this question
4
  • Can you give the exact cron command you are using? (you can make password unreadable if you use it)
    – Catorghans
    Feb 7, 2016 at 16:33
  • 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.
    – thoni56
    Feb 7, 2016 at 19:13
  • crontab: cd $CIVI_ROOT; $PHP bin/cli.php -e Job -a execute -s default -u <user> -p <password>
    – thoni56
    Feb 7, 2016 at 19:32
  • 1
    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;})
    – Jacques-Marie Moranne
    Nov 19, 2016 at 8:48

3 Answers 3

Reset to default
4

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 and here. 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.

Improve this answer
1
  • Although that bug has been fixed, I'm back at the exact same problem. (4.7.17) ;-(
    – thoni56
    Jun 11, 2017 at 9:21
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+

Improve this answer
5
  • 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.
    – thoni56
    Feb 8, 2016 at 20:22
  • 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().
    – thoni56
    Feb 8, 2016 at 20:31
  • 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?
    – thoni56
    Feb 8, 2016 at 21:10
  • 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...)
    – thoni56
    Feb 17, 2016 at 7:19
  • As I just mentioned in in another comment 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.
    – thoni56
    Jun 11, 2017 at 9:23
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)

Improve this answer
1
  • 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.
    – thoni56
    Feb 7, 2016 at 21:10

Your Answer

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

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