By drupeall on

I'm running into odd behavior with drupal when I enable APC.

Specifically the $ _SERVER autoglobal is empty inside of bootstrap . inc

It seems like $ _REQUEST is also empty in other pages which causes some form to have ? for their action attribute.

I had set APC to 'cache_by_default'. Should I turn that option 'Off' and have a specific 'filters' setting? are there certain drupal pages that should not be cached?

Thanks.

⋅ Categories: Drupal 4.6.x

Comments

merlinofchaos’s picture

merlinofchaos commented

I am using the APC opcode cache with all default options, and I haven't run into that kind of thing. How very odd.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

mattman’s picture

mattman commented

I can second the APC issues.

I'm not exactly sure how I might troubleshoot APC further than I have, because I can't find the issue that is causing my site to generate a white page of death. It seems random when it happens but it has happened to me multiple times.

The frequency is not consistent and it can happen shortly after an apache restart or 22 hours later. (my server restarts every 24 hours due to logrotate actions)

The methods I've used to look into this are using the apc.php page that comes with the source and looking at the last watchdog entry to get an idea of the time drupal went dead. I then attempted to correlate with apache's logs for that virtual server. So far I've come up with nothing.

One thing I'm considering doing is creating a shell script that will run under a crontab that uses curl to test the site each minute. If the site is white paged then you get a response of "Empty reply from server". This, however, does not solve the problem of the site going white paged running under normal settings.

If you're wondering about any other sites then yes, it is isolated to my drupal site because I have many other virtual servers and they don't go down. Clicking the "Clear Opcode Cache" button in apc.php clears up the problem. So, my best guess is that drupal doesn't like it when "some page or pages are cached" - from what I can tell.

APC Version 3.0.12p2
PHP Version 5.2.0
Server: Apache/1.3.33

Maybe it's the version of APC, maybe it's a combination, maybe it's drupal. If anyone else has had any APC issues I would love to hear their findings!

My site is here http://www.filemakermagazine.com if you're wondering.

mattman’s picture

mattman commented

As a follow up to my previous comment, I thought I would provide more details and a bit of a fix to having APC White Page of Death problems.

My setup is still running 4.7 and I have a few modules that throw errors under E_ALL. These may be causing the problems because my apache log does not showing anything about its child processes segfaulting.

There is some reasurring info here.

PHP op-code caches / Accelerators where Kahlid talks about the issues of an opcode cache.

Drawbacks of PHP op-code caches: Segmentation Faults

One common drawback of most op-code caches is that they often cause the web server to crash by causing a segmentation fault. From that point on, one Apache process is unavailable. This causes either an error 500 (server error) or the dreaded blank pages (White Screen of Death).

When this happens, you will see a message like this in Apache's error log:

He points to the logwatcher script, but you need to know which log to watch (which is not hard if you know what you're doing). In my case, I'm not getting any notification about segmentation faults - I just get the White Page of Death. My error log is simply empty of any related errors. So my temporary fix is to run a crontab each minute simply checking for an empty site result. Here is the script code I'm using. Simple, but it keeps the site up.

#!/bin/bash

TEST="`/usr/bin/curl -s http://www.mywebsitehere.com/`"

if [ "$TEST" = "" ]; then
        echo "RESTART NEEDED"
        /my/path/to/apachectl graceful
fi

You'll need to have shell access to run this from within your crontab and hopefully your isp allows you to access curl on the command line. In my case, since I have my own server, curl and other potentially harmful apps have been chmodded to root only access. Which means you would need to have both shell and root access to run the script.

But, if you do have shell access with the ability to run curl then this is a good temporary fix.

One thing to note. If you run this on the minute in cron, then you're adding hit stats to your site. (Unless drupal is smart enough to not count the same IP the system is running on). If you're running something like Google's Urchin script then you may want to set up an extra site under the same drupal install. This won't mess up your stats with a hit from your own server IP each minute.

Hope this helps out anyone else who is having issues with APC.

tej_arora’s picture

tej_arora commented

Seeing the white screen of death on some pages.

CENTOS Enterprise 4.7 i686 on virtuozzo
PHP 5.2.6
Apache 2.2.10
APC 3.0.19 stable release

Only apc setting I changed was shm_size (changed from 30M to 64M)

eMPee584’s picture

eMPee584 commented

hi,
might be caused by a default of your linux kernel's shmmax settings which is lower than what you allow apc to use? have a look at /proc/sys/kernel/shmmax:
echo $(($(cat /proc/sys/kernel/shmmax)/1024/1024))
and in case it is less than 64M, maybe put
kernel.shmmax = 67108864 in your /etc/sysctl.conf and run sysctl -p to apply the setting...