2

The Cron tasks on my website run perfectly fine if I manually execute cron. However, I have the server set up to automatically run cron every hour. When cron is executed automatically it fails... every time. The error message is always about memory usage exceeding the allowed levels (which are already rather high). Most of the time, though not always, this error is thrown from the Date module. I do have a feed set up that pulls from a large Google calendar, so I've been thinking that might be the problem. But why would it succeed when run manually? I understand that when run manually it's run as my admin user, and when run automatically it runs (correct me if I'm wrong) as an anonymous user. Does that have something to do with the failure/success pattern?

Edit: Posting the actual cron command as requested

/bin/php5 -q /path/to/my/account/public_html/cron.php

Improve this question
6
  • 1
    Can you try drush? drush cron also does it as uid==0 by default, so that would be a clue. – mpdonadio♦ Jul 1 '11 at 16:11
  • What do you mean by "manually execute cron"? – kiamlaluno♦ Jul 1 '11 at 17:00
  • He means invoking cron from status report page. – Shoaib Nawaz Jul 1 '11 at 17:20
  • Or the link that the admin menu module makes. – mpdonadio♦ Jul 1 '11 at 17:39
  • 2
    Can you update your post with the exact crontab command you're using? – marcvangend Jul 1 '11 at 20:59
3

Check to see if you have a php-cli.ini file being loaded. From the command line, do:

$ php -i |grep ini

and see what ini file is being loaded. If there's a cli ini loading, it may not have the same memory limit as your 'normal' php.ini.

Improve this answer
5
  • That would be my first guess as well. – marcvangend Jul 1 '11 at 20:57
  • Could try adding ini_set('memory_limit', '512M'); to your /sites/default/settings.php I use sudo echo "ini_set('memory_limit', '512M');" | sudo tee -a ./sites/default/settings.php in my drupal install script. – Citricguy Jul 2 '11 at 2:52
  • wouldn't that not affect a cli specific .ini file? – Chaulky Jul 26 '11 at 0:09
  • giving @entendu the accept... see my answer for more details on resolving the issue – Chaulky Jul 26 '11 at 2:04
  • i have a similar issue. I tried to increase the memory limit in settings.php but still the same problem... I don't have access to the command line because it's on a shared hosting. Is there anything else I can try? – jan Oct 25 '11 at 9:47
1

I second trying drush. I was having basically the same problem - I could run cron manually, but could not get curl, wget, lynx, or any of the other crontab variants working. I tried drush cron, and that worked, so... I stuck this in crontab:

45 * * * * /usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin COLUMNS=72 /usr/bin/drush --root=/path/to/your/drupal/root --uri=yoursite.com --quiet cron

Works for me. Saved my sanity.

Improve this answer
1
  • Although simply editing the .ini used by cli and editing your path variables so all programs are readily available from commandline would of probably of solved the issue, this is still handy to know. – stefgosselin Sep 8 '11 at 4:03
0

Depending on what your cron is attempting to do, you might need to specify that it runs as an admin, not anonymous: drush -u 1 cron.

Improve this answer
0

@Entendu was right, it was using a different .ini file than the actual site was using. So when I initiated the cron run manually it was using an .ini file with a higher memory limit than the CLI .ini file. To solve the problem, you could edit the .ini file for the CLI. Or, if you don't have access to it, you can specify that cron should use a different .ini file using the -c flag... /bin/php5 -c /path/to/your/php.ini /path/to/your/cron.php

Improve this answer
3
  • i followed the other path to php.ini above and it gave me this result:X-Powered-By: PHP/5.2.9 Set-Cookie: SESSd41d8cd98f00b204e9800998ecf8427e=3d9ef0bdcafac57380065f61a5d15476; expires=Wed, 07-Dec-2011 15:03:21 GMT; path=/ Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Mon, 14 Nov 2011 11:30:01 GMT Cache-Control: store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Content-Type: text/html; charset=utf-8 what does this mean? – jan Nov 14 '11 at 11:33
  • did you replace "path/to/your/" with the correct path? – Chaulky Nov 14 '11 at 14:41
  • this is the command I typed in: php -c /home/mysite/public_html/mal/php.ini /home/mysite/public_html/mal/cron.php other crons without the php.ini specified are working fine on the same directory... – jan Nov 15 '11 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.