You can set up cron jobs besides the main one driving all the scheduled jobs on the Scheduled Jobs page. The way to do it is explained at http://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs#ManagingScheduledJobs-PHPclimethod
You might have your main job going every 10 minutes like:
*/10 * * * * php /path/to/civicrm/bin/cli.php -s ...
You have to create 3 instances of the mail_report scheduled job.
To do that, use Add New Scheduled Job button on the Settings - Scheduled Jobs page (civicrm/admin/job?reset=1)
On the creation page, set API call to Job / mail_report (api.job.mail_report) and define in Command parameters the appropriate instanceId and format options.
I was able to reproduce your issue and fix it on my Linux install.
It seems to only happen with Linux, not MacOSX.
I can fix it by changing the filename of the job to be first letter caps only, i.e. not camel case. Don't make any other changes.
Following the advice in various other locations, including civix or related issues, does not fix it (shortening, ...
Did you setup the cronjob?
It's the usual behavior of civicrm to send 1000 mails per cronjob. After that it waits x Minutes and sends the next batch of mails at the next cron run.
Just to summarize all the places to look. If you've chosen to try to run CiviCRM cron from Drupal, you need the civicrm_cron module. Then in the Elysia Cron settings: admin/config/system/cron/settings take a look at the settings for the civicrm_cron job and make sure it's enabled. It's probably called: civicrm_cron_cron. Though if you're seeing civicrm_cron ...
The solution is to exclude the iATS job from the "normal catch all" cronjob (so don't put it to run automatically daily)
Then add a line on your cron to run it at 3 am
0 3 * * * www-data nice -n19 /usr/bin/drush -u 1 -r $drupal_root civicrm-api job.whatever-iats-name auth=0 -y
You will need to find what is the name of the iats api job, and put it in the ...
As noted there are various ways documented for scheduling jobs. At our organisation we wanted an easy way to allow our users to set up scheduled email reports and came up with a shared Google Sheet which lets people enter a report instance Id and reporting frequency.
The Sheet uses Google Apps Script to trigger the report generation via the URL method. The ...
All schedule job get saved against civicrm_job. So, by restoring civicrm_job table you can get all the schedule jobs back -
If you are looking for just the standard schedule jobs then try to install the same version of civicrm in different instance and copy the table content to your DB
So after plenty of back and forth, the issue seems to be the fact I am specifying a Source folder in my IMAP account.
When I created a brand new account for testing, found same issue with a folder named CRM. Tried crm in case there was case sensitivity, still the same.
Only when I removed source and let it read from the Inbox directory did it work ...
It looks like you have may not have set a command parameter in the Scheduled Job (but maybe you're adding it when you run the job via URL?). Do you have geocoding=1 in your command parameters for "Geocode and Parse Addresses"?
See Managing Scheduled Jobs from the Civi wiki for reference (2nd row of the table).
The event_queue_id points to a row in the event queue table which has a job id associated with it. The mailing job table is a join table which matches a job to a specific mailing.
Check the civimail reports to give a better idea of the SQL used to construct the queries and extract useful info from the tables
The first one, process_membership, goes around and updates the membership statuses. It's what sets a member's status to "expired" once the end date comes around. Once upon a time, it sent reminders, but it doesn't anymore (new installations don't have that label for the job). You should be able to have it run daily.
The second one, send_reminder, is for ...
Your cron script may not work as displayed because $PHP is not defined, and because PARAMS= -j -smydomain.org -u email@example.com -p xxxxxxxxxx -e Job -a process_mailing will not define $PARAMS without quotemarks surrounding the variable value (instead you get a *sh error).
I suggest adding a MAILTO line with your email at the top so you receive the ...
I would recommend looking in two other places:
The CiviCRM error log. This is to be found (for Drupal) in sites/default/files/civicrm/ConfigAndLog/CiviCRM.(long number).log
The PHP error logs. This is different for each server / Control Panel so I'm afraid I can't give more specific directions than that.
Make sure you find the place in the logs which ...
Here's a trick. Use the API to get relationships with one relationship type and chain an API call to create a relationship with the other relationship type. You have to explicitly say that the new relationship has "0" as the ID, or else it'll just change the relationships you find.
The following example creates a relationship of type 8 for each ...
Yes it sounds like it's hitting an email it doesn't know how to parse - see the code for that function formatMailPart() where it fails (https://raw.githubusercontent.com/civicrm/civicrm-core/master/CRM/Utils/Mail/Incoming.php). Can you tell which email? Anything odd about it? In particular if you view the message source there might be a "Content-Type:" line ...
You may want to try creating a wgetrc file that contains all your values. Check the man page for wget as a reference.. Here's a wgetrc of mine:
output_document = -
Also - check your Apache/nginx logs for the actual URL that was requested that corresponds to a wget ...
Thanks for helping. Looking at the log showed that everything after & was getting truncated.
There should be "backslash" () sign before "and" (&) sign.
/usr/bin/wget -O - -q -t 1
I found the problem. There was a breaking change in CiviCRM over the past year. We were just using the access CiviMail permission for the wordpress user used for sending bulk mail. But it turns out you now need 3 permissions. (I found this in a 3 year old forum posting.)
CiviCRM: view all contacts
CiviCRM: access CiviCRM
CiviMail: access CiviMail
Both of ...
I don't know if this is the case here, and it seems more regular than my experience, but my coworkers and I have seen cron jobs walk fairly regularly. (We're more commonly using Ubuntu 14.04 or 12.04, however.)
The usual issue I see is the following with a daily scheduled job:
cron run starts at 1:00:00
there are a bunch of things to do, so it gets to the ...
The most likely causes for breakage with this change are:
Cron job is pointing to HTTP only
curl by default will not follow 302 redirects, while wget will. If you're using curl, it won't work automatically when pointed to the non-SSL URL (not without -L, anyway). The 302 redirect can make this less obvious, since everything else that points to http "just ...
From your second image, I see that you have not yet set up cron for CiviCRM. The first entry in your crontab executes the Wordpress job. A second entry is needed to execute the CiviCRM job.
Here are the instructions for doing so: https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#choosing-a-method
Had the same problem, on Ubuntu change the system time zone with "sudo dpkg-reconfigure tzdata". Restart the mysql service with "sudo service mysql restart".
Can confirm that this gets the cron running and processing the mailing.