Wp-cron sending emails like crazy

trellis
1

Hello,

I’ve provisioned my server with Trellis. I then set up smtp to MailGun. MailGun allows you to send 10000 email a month free of charge.

At the beginning of last month I got an emial from MG that I’ve almost run out of my 10k limit. I thought - how would that be possible - there is only one live WP site with a contact form. I then thought that I’d secure the form so that it’s more difficult for bots to use the form. So then I implemented Captcha - thought the problem would be over.

In the middle of this month I’m receving similar message from MG that I’ve almost run out of my free quote. After inspecting MG’s logs I found that in fact WP cron is causing this issu, sending emails , several hundred a day. I’ve got thousands of these in the logs:

Retry limit reached. Dropped: root@localhost → web@localhost ‘Cron web@tarasiewicz curl -s http://my_site.net/wp/wp-cron.php’ MX lookup failed

What would be the best way to make WP stop sending theses messages?

2

Not sure what’s causing the problem exactly, but you can always re-enable WP cron to see if that fixes it. Just toggle https://github.com/roots/trellis/blob/5dc3b692c073d4bee4c5f6de3ab977193af8da40/group_vars/production/wordpress_sites.yml#L19 and re-provision your server.

3

This happens on every trellis install I have. I turn off cron messaging in trellis/wordpress-setup/tasks/main.yml

Look at this section - name: Setup WP system cron

and add > /dev/null 2>&1 to the end of the line, like so:

job: "curl -s {{ item.value.env.wp_siteurl }}/wp-cron.php > /dev/null 2>&1"

Then re-provision your server. On your remote server, the file is located at /etc/cron.d/wordpress-YOUR_SITE_NAME

In case you want to edit it manually. That’s how I disable attempted emails that you are seeing.

5 Likes
4

@nbyloff, Thanks so much for this solution.

6

Hi @nbyloff

I tried doing this and reprovision the server.
The flie /etc/cron.d/wordpress_domain_com did changed into this

#Ansible: domain.com WordPress cron */15 * * * * web cd /srv/www/domain.com/current && wp cron event run --due-now > /dev/null 2>&1

But Mailgun is still logging this

Retry limit reached. Dropped: root@mg.domain.com → web@mg.domain.com 'Cron <web@server> cd /srv/www/domain.com/current && wp cron event run --due-now' MX lookup failed

with details json format (truncated)

"message": {
    "headers": {
      "to": "web",
      "message-id": "20160825083006.82493.45993.675EBA03@mg.domain.com",
      "from": "root (Cron Daemon)",
      "subject": "Cron <web@server> cd /srv/www/domain.com/current && wp cron event run --due-now"
    },

The Ansible script now is like this

- name: Setup WP system cron
  cron:
    name: "{{ item.key }} WordPress cron"
    minute: "*/15"
    user: "{{ web_user }}"
    job: "cd {{ www_root }}/{{ item.key }}/{{ item.value.current_path | default('current') }} && wp cron event run --due-now > /dev/null 2>&1"
    cron_file: "wordpress-{{ item.key | replace('.', '_') }}"
  with_dict: "{{ wordpress_sites }}"
  when: site_env.disable_wp_cron and not item.value.multisite.enabled | default(false)

Thanks for your help!

7

I’ve added –quiet to my job line, like this:

job: "cd {{ www_root }}/{{ item.key }}/{{ item.value.current_path | default('current') }} && wp cron event run --due-now --quiet"

The option is documented at the end of the right column here:

http://wp-cli.org/commands/cron/

It says it will “Suppress informational messages.” but hopefully not real errors (note: I haven’t tested).

At least the e-mails stopped :grinning:

1 Like
8

Hi all! I am also running into this error. I’ve added --quiet to the cron task but the emails still keep happening.

Is it possible that something is retrying the same email over and over again?

Thanks so much for the help!

9

I am also running in to this issue. I’m getting 4 email (2 for staging, 2 for production) every 15 minutes that are attempting to be sent to web@{website-url}.

Just tried adding --quiet to the cron but no change. Emails just went out at the 9:30am mark here. About to try piping to dev/null and see if that helps.

EDIT:
It looks like adding > /dev/null 2>&1 and reprovisioning has stopped the emails from being sent. Is there anything I should be concerned about with this fix?

10

Do cron events still get logged by the system, or is that disabled with this solution too?

11

They are in your syslog still

1 Like