7
The cron job you have there looks like a Drupal cron job. You should look at the scheduled jobs wiki page for full details, but in the case of a Drupal site using wget (since that is the direction you're seeming to go in), try:
*/6 * * * * wget -O - -q -t 1 http://mydomain.com/sites/all/modules/civicrm/bin/cron.php?name=username&pass=password&key=...
6
See here: https://en.wikipedia.org/wiki/Cron
It's probably not that it's stopping - but that it was never set up. CiviCRM won't do any tasks that need to happen automatically - including sending mails, updating membership statuses, etc. - until you set up cron. I don't think any of the CMSes that support CiviCRM work reliably without setting up cron, ...
answered Mar 20 '16 at 16:41
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
6
Smart groups are kind of complicated. If you've got a small install, using the defaults will generally just work, i.e. there will be temporary caching that gets refreshed when necessary.
To answer your first question though, smart groups are updated depending on the timeout configuration and/or the scheduled job, and also depending on urls being loaded.
To ...
4
You need to turn on "Access all custom data" for anonymous users for a lot of very popular features (e.g. custom fields for anonymous users in profiles and webform_civicrm) to work. Someone else can contradict me, but I'm reasonably certain this has no impact on security unless a) anonymous users also have access to contact records, or b) you have custom ...
answered Jan 15 '16 at 20:13
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
4
As PHP develops, some code that used to work in older versions fails in newer versions. The CiviCRM code gets updated to accommodate those changes - but obviously if you don't upgrade you don't get those fixes.
Your fix is to downgrade the version of PHP, then upgrade CiviCRM, then upgrade PHP again. You can find a table of supported PHP vs CiviCRM ...
3
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 ...
3
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
http://www.site.org/wp-content/plugins/civicrm/civicrm/bin/cron.php?name=XXXX\&pass=XXXX\&key=XXXXX
3
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:
post-data=name=civicron&pass=<password>&key=<sitekey>
output_document = -
quiet=on
timeout=1
Also - check your Apache/nginx logs for the actual URL that was requested that corresponds to a wget ...
answered Feb 13 '16 at 21:08
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
3
I would look at the scheduled_date on the mailings in your database:
SELECT name,scheduled_date FROM civicrm_mailing;
If the scheduled_date is off, then it might be that MySQL has a time mismatch - or that specific users in Joomla have a different timezone setting than the default (not sure if this is possible in Joomla, but it can be done in WordPress/...
answered Mar 2 '18 at 15:00
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
3
If you run the schedulded job as a cron job and don't use the http-method for the setup you will not face a php runtime timeout. We did have no issues with schedulded jobs running multiple hours.
3
The cron url seem to be wrong, it should have been
https://mysite/wp-content/plugins/civicrm/civicrm/bin/cron.php?name=<username>&pass=<password>&key=<site-key>
3
First, you can view the error with greater detail if you enable "Debug and Backtrace", or view the CiviCRM log. The troubleshooting documentation will tell you how to do both.
Second, I would assume that "connect failed" is a MySQL error. Is it possible that you have two civicrm.settings.php files in your path, one with the wrong MySQL password?
Finally -...
answered Jul 6 '18 at 20:08
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
3
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.
3
Can you please check MYSQL and PHP are using the same timezone? This sometimes happens when both are running on different timezones.
You can find a solution for similar sorts of issues here.
2
I had exactly this problem too and it seemed to me that the missing class should have been loaded earlier in the sequence. In Civi 4.6 there is an extra statement on line 646 of /home/[USERNAME]/public_html/info/administrator/components/com_civicrm/civicrm/CRM/Utils/System/Joomla.php so I made my 4.4.20 version look like this (with Joomla 3.4.5):
if( ...
2
This is a known bug in CiviCRM 4.7.1.
EDIT: Based on new information on this bug report, this problem does NOT exist when using wget. Also, someone in the community has stepped up to pay for this bug to be fixed, so expect a solution soon!
answered Feb 11 '16 at 5:29
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
2
wp-cli doesn't bootstrap the settings, so doesn't load the timezone.
Because of this exact issue, I wrote a patched version of the CiviCRM extension for wp-cli to add timezone support. It's available here. As far as I can tell, the original author has abandoned the project, because they haven't merged any pull requests (including this patch) in over a ...
answered Feb 11 '16 at 5:33
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
2
It seems like you have several errors listed. I would start by addressing the most serious first. You'll need to reinstall CiviCRM after enabling the InnoDB database engine in your MySQL instance (see https://stackoverflow.com/questions/4757589/how-to-enable-innodb-in-mysql).
2
problem found... it was a confusion between 2 scripts
/home/sitename/www/www/private/civicron.sh
/home/sitename/private/civicron.sh
After adapting the correct script it seems okay.
2
So CLI's memory limit was set to -1 like this:
memory_limit = -1 // no memory limit
Setting the limit to other than no limit solved the issue.
I'm not sure why this happened as CLI's memory limit was always set to -1 from the very first day I configured this server 2 years ago.
2
A similar-sounding bug report has been filed here:
https://issues.civicrm.org/jira/browse/CRM-18514
There are scattered reports of cron-related issues in 4.7 but people have been not giving detailed enough information to really pin the problem down. Can you say exactly how you have your Civi cron jobs configured to run? From your question it is not clear ...
2
No, ACLs are about including groups you can see, not about excluding the ones you can't.
What we did for a case like you was to automatically add any new contact into a "visible by everyone" group and remove it if/when they are added to the "VIP" group. So what you do with smartgroups, but because we add/remove directly, it was faster as no need to wait for ...
2
check out this very detailed answer on a different SE site by Chris:
https://drupal.stackexchange.com/questions/136722/drupal-7-cron-does-not-run-civicrm-scheduled-jobs
2
What I've done to fix this is create a bash script that executes the civicrm api command, captures the output to a variable, tests for the string [is_error] => 0, if there's no match, then it echos the output of the command.
Here's the script:
#!/bin/bash
output=$(/usr/local/bin/wp --user=cronuser --url=https://mysite.org --path=/srv/www/mysite.org/...
2
My standard for Drupal cron is to only run it every 8 hours. Unless you use modules that expect a more frequent update (e.g. to pull in RSS feeds in a timely manner) you should be fine turning it off for a day.
answered Nov 18 '16 at 20:30
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
2
The error message comes from here and indicates that cron.php is not bootstrapping the WordPress CMS, so WordPress functions aren't available.
WordPress is_admin() is defined in wp-includes/load.php. If WordPress was initialised, that function would be present.
If you are able to configure your cron to execute via commandline (eg wp-cli method or PHP CLI ...
2
whereis wp showed wp: /usr/bin/wp, so I tried that in crontab and the problem appears to be solved!
System Status no longer says cron is not running and the "Last Run" column on Scheduled Jobs listing shows that the jobs have run.
successful crontab entry:
*/15 * * * * /usr/bin/wp --user=cronuser --url=http://mydomain.org --path=/myserver/homepages/34/...
2
I solved the issue with the help of xurizaemon on the Mattermost chat channel.
The script was failing because it was trying to delete a membership that looked like it was already deleted.
Hints below:
so "call to member function delete() on null" means that CiviCRM
expected there to be an object and called a method on it - but the
object didn't ...
2
Two answers: First, yes, changing the permission should be safe to do. Note, however, that you'll have to repeat this process every time you upgrade.
Second - this isn't a normal restriction, so I'm guessing you're running CiviCRM on shared hosting. The change you described removed the "group owner can write to this file" permission of cron.php. You did ...
answered Aug 17 '17 at 15:00
Jon G - Megaphone Tech
28.1k1 gold badge21 silver badges78 bronze badges
2
I may have solved this with the following steps.
create a drush alias for the site
configure crontab using the drush alias
Drush alias (~/.drush/example.aliases.drushrc.php)
<?php
$aliases['example.com'] = array (
'uri' => 'example.com',
'root' => '/path/to/drupal',
);
?>
Crontab
0 * * * * drush -u 1 @example.com ...
Only top voted, non community-wiki answers of a minimum length are eligible
