CiviCRM Community Forums (archive)

You have a scripted job set up to handle mail bounces from CiviCRM. It looks like someone has followed the instructions from the CiviMail setup docs incompletely; the command is supposed to be

wget http://donations.earthsave.org/path/to/civicrm/bin/civimail.cronjob.php?name=admin&pass=xxxx

A couple of changes need to be made:

1. Add "wget" to the start of the command
2. Fix the path to CiviCRM to be the actual path to CiviCRM on your server

I think what you want in the cron job is,

wget -q --spider http://donations.earthsave.org/civicrm/bin/civimail.cronjob.php?name=admin&pass=xxxx

If you don't have wget, you probably have curl, which wants these args

curl -o /dev/null -s http://donations.earthsave.org/civicrm/bin/civimail.cronjob.php?name=admin&pass=xxxx

The -q and --spider arguments will ensure that wget doesn't return anything, so you don't get a mail every five minutes.

You'll need to ask your server admin (or whoever set up CiviMail for you) to do this.

(You should also change your admin password ASAP.)

@DenverDave - can you post the wget or curl command you are using which leaves a file behind? I suspect it's wget, as curl doesn't save a file by default. (Don't include your password in the posted command though!)

You can prevent a file being saved to disk using either of the following arguments for wget:
-O /dev/null--spider
To prevent an email being generated each time the cron job runs, you can use the following argument for wget:
-q
Putting them together, we use one of the following formats (some systems have wget by default, others curl, both do the same job fine):
wget --spider -q 'http://my.host.name/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=USERNAME&pass=PASSWORD'
curl -o /dev/null -s 'http://my.host.name/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=USERNAME&pass=PASSWORD'

@chartglass - If your cron job is still running 60 times an hour (ie, every minute), you should know this can cause issues if server load means that a job takes more than 60 seconds to complete. This situation can result in many jobs being run concurrently, with compounding effects, and overload the server quicker than you might anticipate.

The cron syntax to specify how often it runs uses the first column to specify the minute of the hour it should run at. Instead of a * here, using a */5 or */15 will result in the job running once every five / fifteen minutes, which is far less likely to cause problems.

I expect that CiviCRM prevents concurrent issues internally anyway, using some kind of lock to prevent multiple concurrent CiviMail jobs. Still, it might help for you to know how to prevent cron jobs misbehaving in case you have other automated tasks.

Batch limit set to 200, running the CiviMail cron job at five minute intervals
*/5  *  *  *  *  curl -o /dev/null -s 'http://my.host.name/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=USERNAME&pass=PASSWORD'

In your situation I'd probably test out what some settings that might work were, by doing something like:

• set the batch limit higher than you'd usually do (say 500)
• run the cron job manually a few times with 'time'
  time curl -o /dev/null -s 'http://my.host.name/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=USERNAME&pass=PASSWORD'

That should tell you what settings your system is capable of handling. This will really depend on whether you're running a local mailserver, or a remote one (and: how remote).

Then, halve the batch limit and multiply the time you expect each run to take - if it only took 45 seconds to run the batch, I'd allow it five minutes; if it took more I'd probably allow ten minutes, or more.

Hope that helps. This is fairly unscientific by the way, but hopefully it'll give you an idea of how to identify some limits that will work for you!

I found this a really useful thread. However, I was not clear how to determine the batch size. I am using wget and have therefore adopted this:

wget --spider -q 'http://my.host.name/sites/all/modules/civicrm/bin/civimail.cronjob.php?name=USERNAME&pass=PASSWORD'

Thanks

Any idea what an optimal batch size might be?  For now we are set at 50 emails every 10 minutes, but I have no idea if we might be better at 5 emails every 1 minute or 300 every hour.

Dave

Any idea what an optimal batch size might be?  For now we are set at 50 emails every 10 minutes, but I have no idea if we might be better at 5 emails every 1 minute or 300 every hour.

As Lobo pointed out, this must be weighted by yourself, based on (a) the host’s limits (if any), (b) the host’s performance capabilities and (c) your requirements for the promptness of the mailing.

If the limits are hour-based and the host doesn’t have any performance problems when handling 300 emails at a given time I’d go with sending a bit below the limit (as Lobo suggests) every hour, but if the host acts better with lower load (and it’s not crucial that the recipients get their emails ASAP), you might want to go with 50 emails every 10 minutes (or five emails every minute).

(Note that the above counts are rather small, and neither should pose any performance problems; I’m writing more about the general case.)