Author Topic: Cron jobs from php cli failing CiviCRM-4.0.1 (Read 5328 times)

circlebails · May 20, 2011, 06:02:03 am

Hi

Using the shell script below:

#!/bin/bash
umask 002
PARAMS='-u<username> -p<pass> -smysite.tld'
cd /var/aegir/platforms/justforcivi-7.0/sites/all/modules/civicrm/
/usr/bin/nice -n19 /usr/local/bin/php bin/UpdateMembershipRecord.php $PARAMS

With a settings_location.php setup correctly, the script returns with no errors, but nothing happens.

However when I run:

/usr/bin/wget -O - -q -t 1 --post-data='name=<username>&pass=<pass>&key=<key>' 'http://mysite.tld/sites/all/modules/civicrm/bin/UpdateMembershipRecord.php'
Updating ........
Membership records updated. (Done)

The same applies to civimail.cronjob.php

Am I misunderstanding something?

Thanks

Bails

narayanis · June 05, 2011, 11:14:42 am

I am experiencing the same issue with my civimail cron job on 3.4.2. I set it up like this (I use Barracuda/Octopus and Aegir):

Code: [Select]

PARAMS='-smysite.org -umyuname -pmypass'
cd /data/disk/octopusadmin/platforms/pcfs-stage/sites/all/modules/civicrm;
php bin/civimail.cronjob.php $PARAMS

I run it like this:

Code: [Select]

bash civicron.bash

or like this:

Code: [Select]

sh civicron.bash

There was an error before, referencing the need to create a new settings_location.php. I did that and set it properly. The file runs without errors now, but the mail page never shows the job start and nothing is sent. Any advice?

xavier · June 05, 2011, 11:23:06 am

Just to be sure on your drupal, you have your configuration under /sites/mysite.org (ie no default) ?

I don't know, I remember having had difficulties running it (was something about bootstrapping drupal if I recall), but civicrm core tested and was working fine on their side.

Can you verify your php-cli is configured to display errors and check the error level ?

narayanis · June 05, 2011, 01:32:26 pm

That's correct, the site folder is the name of the domain (which Aegir does auto-magically). I've seen Drush have issues trying to bootstrap Drupal when running a Drush command from the sites/all folder rather than the sites/mysite.org folder.

My php.ini file is set to E_ALL & ~E_NOTICE.

I would use the wget or curl method like I used to do on shared hosting, but Nginx blocks them to prevent DoS attacks so I have to do it as a script now.

narayanis · June 05, 2011, 01:51:29 pm

Is it perhaps a configuration issue elsewhere I have wrong? The info I read said to place settings_location.php in the CiviCRM module folder, which is located at sites/all, and the parameter points to the Drupal root. How does the process determine which site folder to look in (i.e. which CiviCRM config file to read) to ensure it's running against the right db?

xavier · June 05, 2011, 11:25:12 pm

Quote from: narayanis on June 05, 2011, 01:32:26 pm

My php.ini file is set to E_ALL & ~E_NOTICE.

That's a different php.ini for the cgi and cli. 100% sure it's the right one you are looking at ?

Quote from: narayanis on June 05, 2011, 01:32:26 pm

I would use the wget or curl method like I used to do on shared hosting, but Nginx blocks them to prevent DoS attacks so I have to do it as a script now.

In my experience, less ressource intensive to do via the cli (you avoid all the web layer overhead), plus you can have different settings (eg on max memory) and you can it run on a lower priority than the web.

Quote

How does the process determine which site folder to look in (i.e. which CiviCRM config file to read) to ensure it's running against the right db?

That's what the -s param is for: you need to put it with the name of the folder under sites.

try to put a "die('blablabla')'" in the civicrm.setting in the folder, see if it loads it.

Other than that, I'd suggest you to go down the script code path and put die("XXX"). Until it goes blank.

(check one more time if it displays error on the cli php, that's something I often have to modify on the default debian config).

X+

narayanis · June 07, 2011, 09:25:01 am

I told php where to find my ini file (which is set to E_ALL and E_NOTICE) and ran this:

Code: [Select]

php --php-ini /usr/local/lib/php.ini /data/disk/octopusadmin/platforms/pcfs-stage/sites/all/modules/civicrm/bin/civimail.cronjob.php -smysite.org -unarayanis -pmypass

I'm not even running it in a .bash file anymore, I'm entering this exactly on my command line (with the real site folder and password). Actually, I can enter an invalid site and password but get the same result; no errors, no feedback, just a new line in the command window waiting for my next command. Any other advice?

Donald Lobo · June 07, 2011, 09:36:52 am

a few thoughts:

1. I would add echo / die statements in civimail.cronjob.php and see whats happening. Seems quite wierd behavior, and does not seem to be running

2. might be easier to discuss and make progress with this on IRC

lobo

xavier · June 07, 2011, 09:52:39 am

Add that in the code after civicrm_initialize():
(or anywhere, really);

ini_set('display_errors','On')

narayanis · June 07, 2011, 08:19:37 pm

Assuming you meant civicrm_initialize() in drupal.module, I added the ini_set, ran a drush cc all, and received the same result. No errors, regardless of whether I use a good or a bad password. I am glad to provide SSH credentials or do any other troubleshooting you think would be helpful.

On a side note, I'm heading to DrupalCamp SC this weekend to present a session introducing Civi as the best open-source CRM for nonprofits. Very much looking forward to it.

circlebails · June 22, 2011, 04:36:33 am

Just adding to this after looking at it again and upgrading a site to 3.4.3.

under 3.3.5 the below works fine.

/bin/nice -n19 /usr/bin/php bin/EmailProcessor.php -u civimail -p X07rb12BD -s foo.org.uk

under 3.4.1 with a now required settings_location.php

/bin/nice -n19 /usr/bin/php bin/EmailProcessor.php -u civimail -p X07rb12BD -s foo.org.uk

Fails to return anything and there is nothing recorded in the relevant mailservers logging indicating that the associated mail user logged in.

So it appears that both 3.4.X and 4.X have the same problem.

xavier · June 22, 2011, 05:58:50 am

Hi,

Does the cron to send emails work fine on the same config ?

I'm assuming that foo.org.uk has been moved and contain the same stuff than before;

What do you mean by settings_location.php needed ?

(rings a bell of a previous conversation with Kurund about an issue I had but they couldn't reproduce).

That would be awesome if you could investigate asap, we got a tiny window to push the correction before the next release.

X+

circlebails · June 22, 2011, 06:29:25 am

"What do you mean by settings_location.php needed ?"

/bin/nice -n19 /usr/bin/php bin/civimail.cronjob.php -u civimail -p X07rb12BD -s foo.org.uk

Usage: Please define CIVICRM_CONFDIR in settings_location.php at the top level civicrm directory

"Does the cron to send emails work fine on the same config ?"

Well dropping a location_settings.php into the correct place and running the above results in no output and no email sent, confirmed this by running the script from wget which does work.

Cheers

Bails

xavier · June 22, 2011, 07:21:31 am

Weird,

Can you try something: in CRM/Utils/System/Drupal.php cmsRootPath ?

Code: [Select]

    static function cmsRootPath( )
    {
        $cmsRoot = $valid = null;
        global $civicrm_root;

        if (file_exists ($civicrm_root. '/settings_location.php')) {
            require_once ($civicrm_root. '/settings_location.php');
            return CIVICRM_CONFDIR . "/..";
        }

(add the last if bloc)

circlebails · June 23, 2011, 02:58:37 am

Hi Xavier

I tried this

static function cmsRootPath( )
{
global $civicrm_root;$cmsRoot = $valid = null;

//We added This
if (file_exists ($civicrm_root. '/settings_location.php')) {
require_once ($civicrm_root. '/settings_location.php');
return CIVICRM_CONFDIR . "/..";
}

However nothing is outputed on the cli when running either:

/bin/nice -n19 /usr/bin/php bin/UpdateMembershipRecord.php -u civimail -p X07rb12BD -s foo.org.uk
/bin/nice -n19 /usr/bin/php bin/EmailProcessor.php -u civimail -p X07rb12BD -s foo.org.uk
/bin/nice -n19 /usr/bin/php bin/civimail.cronjob.php -u civimail -p X07rb12BD -s foo.org.uk

And tailing the mailserver logs when running EmailProcessor.php the use never logs in.

Thanks

bails

CiviCRM Community Forums (archive)

News:

Author Topic: Cron jobs from php cli failing CiviCRM-4.0.1 (Read 5328 times)

circlebails

Cron jobs from php cli failing CiviCRM-4.0.1

narayanis

Re: Cron jobs from php cli failing CiviCRM-4.0.1

xavier

Re: Cron jobs from php cli failing CiviCRM-4.0.1

narayanis

Re: Cron jobs from php cli failing CiviCRM-4.0.1

narayanis

Re: Cron jobs from php cli failing CiviCRM-4.0.1

xavier

Re: Cron jobs from php cli failing CiviCRM-4.0.1

narayanis

Re: Cron jobs from php cli failing CiviCRM-4.0.1

Donald Lobo

Re: Cron jobs from php cli failing CiviCRM-4.0.1

xavier

Re: Cron jobs from php cli failing CiviCRM-4.0.1

narayanis

Re: Cron jobs from php cli failing CiviCRM-4.0.1

circlebails

Re: Cron jobs from php cli failing CiviCRM-4.0.1

xavier

Re: Cron jobs from php cli failing CiviCRM-4.0.1

circlebails

Re: Cron jobs from php cli failing CiviCRM-4.0.1

xavier

Re: Cron jobs from php cli failing CiviCRM-4.0.1

circlebails

Re: Cron jobs from php cli failing CiviCRM-4.0.1