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=...
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, ...
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.
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 ...
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 ...
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 ...
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
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 ...
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/...
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?
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.
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):
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!
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 ...
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).
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.
A similar-sounding bug report has been filed here:
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 ...
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 ...
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:
output=$(/usr/local/bin/wp --user=cronuser --url=https://mysite.org --path=/srv/www/mysite.org/...
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.
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 ...
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/...
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.
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 ...
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 ...
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)
$aliases['example.com'] = array (
'uri' => 'example.com',
'root' => '/path/to/drupal',
0 * * * * drush -u 1 @example.com ...