2

I can send an email from any other area of Civi. For example if I select a contact and send an individual email, it works...

BUT CiviMail - IS DRIVING ME CRAZY!!!

I am routing all email to spamexperts (using SMTP setting in Civi Admin) and again, it all works in other areas of the website, and even any other area of Civi itself.

I've check and confirmed the CRON job runs, I am even running it manually again just to be sure. The CRON job for "send mailings" shows in the log that there is no errors, and everything is "sent" but it doesn't ever send any emails.

If I check the spamexperts delivery logs, I can see all my other emails going through that I send from other areas of Civi, but there is NO record of the civimail mailings even getting to spamexperts.

I am at a total loss, any ideas anyone? I owe you big time if you can point me in the right direction!

  • 1
    Just to be clear, when you're 'running it manually' - do you mean running something from the command line, or going to Administer > System Settings > Scheduled Jobs, find Send Scheduled Mailings then more > Execute Now ? I have seen situations where Execute Now works but running via cron fails because of permissions. – Aidan Apr 28 '17 at 7:42
  • Does your mailing report show the correct number of mails sent? What does your CiviCRM log (in ConfigAndLog directory) show, if anything? – Jon G - Megaphone Tech May 2 '17 at 4:25
  • I can run manually via scheduled jobs, and it "says" it has run properly. ALSO - the CRON does work, there was an issue with Joomla 3.7.0 that messed up cron jobs, but 3.7.1 did fix that. So all my cron jobs fire off and run, BUT the email never gets to the recipient. – John Shoff May 18 '17 at 21:58
1

It's not easy to get it working properly indeed.

Sending a "normal" email and civimails follow a different path. The former is simple: you call the "send an email" you configured (usually the mail() function, but can be configured, eg to use smtp directly), wait until it's done and that's it.

This doesn't scale and if you aim, like civimail does, at sending lots of emails, you need to queue these emails, possibly split them in separate batches and have a cronjob that process them in the background to send these emails

And were it becomes even more complicated is that you have a lot of different ways to run that cronjob, because civicrm aims at serving a lot of different configurations.... and each have lots of opportunities to have something not working.

As you are using joomla, the "common solution" we use (drush) isn't an option. You do not detail your system, do you:

  • have access to the command line (ssh)
  • can set up cronjobs
  • have php-cli installed and with the same configuration as the php used for your server?

You haven't described enough how have configured CiviCRM. If this is not how you are using it, could edit your question and add these details and what you get if you run

path/to/php /path/to/civcrm/module/bin/cli.php -s site -u user -p password -e Job -a execute

As described: https://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs

  • The scheduled job works, cron is setup and working 100%. it shows in the scheduled job logs that it ran sucessfully, it just never actually RUNS the cron job! I just don't know where to look from here to see what is blocking the email from going out. ALSO - if i go into a contact directly in Civi and send them an email, it does send just fine, so Civi sends email from any other module, JUST the civimail doesn't work – John Shoff May 18 '17 at 22:00
0

I had this same problem working through setting up a new CiviCRM instance. There was indeed a lot of set up, but I wanted to share some of it.

TIL Cron isn't enabled by default

Cron does not execute in the same context as the shell testing job.execute. For me, I was running cv api --user=admin job.execute and it was working fine. However, adding that to crontab did not execute the task. To get cron running, I had to do the following:

  1. sudo service cron status told me cron wasn't even executing! sudo service cron start solved that
  2. To view the cron logs, I uncommented the cron line sudo vi /etc/rsyslog.d/50-default.conf
  3. To view cron executions tail -f /var/log/cron.log

The job executes, but what is the result?

Now I knew the command was running, but what was it doing? I modified the cron job to show me crontab -e

* * * * * /usr/local/bin/cv api --user=admin job.execute > /tmp/cv.cron.log 2>&1

Now I can see the failures, which was cv not finding civicrm.settings.php file. This is where the context of cron differs from my shell. I run env in my shell and compare it to cron's. By creating a new cron job:

* * * * * env > /tmp/cron.env.log

less /tmp/cron.env.log after tail -f /var/log/cron.log to make sure it ran. There's no environment! My path is /usr/bin:/bin. No wonder cv cannot find my site.

Change the current working directory & Use absolute paths

I changed my cron job to change directory into the /drupal/sites/default folder and now my cron jobs show up. My full crontab command:

* * * * * cd /home/andy/git/drupal/sites/default && /usr/local/bin/cv api --user=cron job.execute > /tmp/cv.cron.log 2>&1

I'm sure your paths will differ. Now that I can see the json response I can remove the > /tmp/cv.cron.log 2>&1

TL;DR

cron needs to know where your files are.

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.