HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Server Operation (http://www.howtoforge.com/forums/forumdisplay.php?f=5)
-   -   Apache misreading PHP files after file and directory modifications (http://www.howtoforge.com/forums/showthread.php?t=55689)

cbj4074 9th January 2012 17:09

Apache misreading PHP files after file and directory modifications
 
I have a shell script that I use to "build" a PHP application on a development server.

Some percentage of the time, this build process causes Apache to interpret PHP files incorrectly.

In particular, I see error message that make absolutely no sense, such as "Class XYZ cannot be redeclared in file.php", even though the class in question is declared only once.

Another common error message is that a given file that is require()d is missing, even though the file is, in fact, present on the filesystem.

The only way I've been able to fix these problems when they occur is to restart Apache. As soon as I restart Apache, all of the errors disappear and the website/application functions as expected.

Because restarting Apache fixes the problem(s), Apache seems to be at fault.

Does anyone know if Apache "caches" files in some manner when running under ModPHP? I can't think of any other reason for this behavior.

It seems absurd that Apache would malfunction when files are added/deleted/moved on the filesystem, as any shared hosting environment would be plagued by such an issue.

The build script that I'm using performs the following actions:

1.) Delete all contents in website's document root.

2.) Export SVN repository contents to website's document root.

3.) Copy configuration files (not stored in SVN repo) into place.

4.) Copy .htaccess.txt to website document root and rename to .htaccess.

5.) Reset permissions on website document root (a series of chown and chmod commands).

The website in question is running under ModPHP.

I thought about changing the PHP mode for this website to Fast-CGI and seeing if the problem still occurs, but this will take considerable effort on my part, so I figured that I'd ask here first.

Thank you for any insights.

till 9th January 2012 18:15

Do you use some kind of binary cache like eaccelerator, xcache or similar? If yes, have you tried to disable it.

cbj4074 9th January 2012 21:54

Hmm, now that you mention it, APC ( http://php.net/manual/en/book.apc.php ) is installed and enabled on this server.

I bet that's the problem.

APC was installed to enable upload progress bar functionality.

Now that we know that the problem is related to APC, it was easy to find people reporting similar problems:

https://bugs.php.net/bug.php?id=57203

Maybe this is simply a bug, or maybe APC can be configured to allow for this kind of "building" behavior.

Thanks for the help, Till! :cool:

till 9th January 2012 23:13

I use xcache on my servers instead of apc. Maybe it works nbetter for you as well.

cbj4074 10th January 2012 22:18

Great, thanks, I will look into xcache.

In the meantime, I think I found the configuration directive to change:

apc.stat_ctime (integer):

Quote:

Verification with ctime will avoid problems caused by programs such as svn or rsync by making sure inodes haven't changed since the last stat. APC will normally only check mtime.
This sounds like exactly the issue I've been grappling with. I'll post back once I've had a chance to see how the server response with apc.stat_ctime set to On.


All times are GMT +2. The time now is 22:35.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.