The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.This should be because I've setup drush cron runs via linux's cron AND forgot to disable the poormanscron module....
Every one or two or 5 days I get an email from my linux cron about that ...
Here is the email (drc is the bash script that invokes all drush crons on all our sites):
(Speicherzugriffsfehler should mean Segmentation Fault)
----------------
Cron drc -a 2>&1 >/var/log/drupal_crons_all.log
/home/shared/bin/drc: Zeile 38: 18264 Speicherzugriffsfehler drush cron
----------------
Issue posted for anyone googling with the same problem...
Please, wait for a further report here telling you that after disabling all poormanscrons for 2 weeks no error was seen...
Comments
Comment #1
rsvelko commentedactually the above bug showed twice today in the last 40 minutes... sth is wrong - what could this be?
I use drush version:
/README.txt/1.25/Thu Jun 4 03:10:41 2009//
/drush/1.8/Tue Aug 18 19:17:29 2009//
/drush.api.php/1.2/Tue Aug 25 19:05:27 2009//
/drush.bat/1.1/Mon Jun 11 13:56:00 2007//
/drush.php/1.69/Tue Jun 30 01:01:59 2009//
/example.drush.inc/1.3/Wed Apr 15 01:13:45 2009//
/example.drushrc.php/1.11/Sun Apr 19 03:13:09 2009//
D
Comment #2
rsvelko commentedSee here: http://groups.drupal.org/node/20631 - "E accelerator Segmentation Error"
and here: http://www.drupalarchitect.com/drupal-segmentation-fault-using-eaccelera...
I quote the last one entirely below:
------------
"Drupal segmentation fault using eAccelerator or X-Cache.
Tue, 01/06/2009 - 22:31 — architect
This error can show up as a blank page, or a page with a header stating zero byte sized reply. Check your logs, and if you find a segmentation fault error, it could be becouse of your opcode cache. The fix is to use APC cache (Alternative PHP Cache) instead of eAccelerator or X-Cache. X-Cache and eAccelerator both have known issues when used as a opcode cache with Drupal under a heavy load.
Why use an opcode cache? Using an opcode cache is an absolute must in a LAMP environment. This cache stores pre-compiled code in memory or on the file system, so that the code does not have to be compiled every time the page is served. This greatly improves page serving speed, and cuts down on CPU load."
----------------
Search "APC php" on google for installation instructions for APC.
It is 99% a eAccelerator issue. After reading the above I am thinking to move to APC. Increased all memory limits in the meantime..
Will write back in a week.
Comment #3
rsvelko commentedthis is not drush's fault..
Comment #4
rsvelko commentedToday I had 2 more segmentation faults because of my drush cron running with eAccelerator....
The last increase of memory limits did not do it. APC should do it then.
I will write back to tell whether APC solved it - after 2 weeks it will tell.
Comment #5
rsvelko commentedI migrated to APC, and removed all drupal sites that gave some kind of an error on cron run via drush... And still I get this error . Maybe I should try to invoke cron with cron.php and wget ...
Moving to active state cause I need someone to look at this ... Anyone?
Comment #6
rsvelko commentedinvoking with wget does not give me those errors anymore. So this is somehow related to php-cli...
Anyway people that google about this will find it . Marking it fixed for now.
Comment #8
philsward commentedJust ran into this same issue using APC... I restarted Apache which (temporarily) fixed the problem.
I recently added the following which I'm sure is the root of my problem, but I'm not exactly sure at this point:
apc.ttl = "15"
apc.user_ttl = "15"
apc.stat = "0"
Oh, and I'm also getting an error_log stating:
[13-Apr-2012 02:54:09] PHP Fatal error: PHP Startup: apc_mmap: mmap failed: in Unknown on line 0