2

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.

  • Can you give the exact cron command you are using? (you can make password unreadable if you use it) – Catorghans Feb 7 '16 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 '16 at 19:13
  • crontab: cd $CIVI_ROOT; $PHP bin/cli.php -e Job -a execute -s default -u <user> -p <password> – thoni56 Feb 7 '16 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 '16 at 8:48
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.

  • Although that bug has been fixed, I'm back at the exact same problem. (4.7.17) ;-( – thoni56 Jun 11 '17 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+

  • 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 '16 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 '16 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 '16 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 '16 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 '17 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)

  • 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 '16 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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