Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 366489 - dev-php5/pecl-apc-3.1.8 - Fatal error: main() [function.require]: Failed opening required 'filename.php' (include_path='.:') in on line 429
Summary: dev-php5/pecl-apc-3.1.8 - Fatal error: main() [function.require]: Failed open...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PHP Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-08 18:38 UTC by Dominik
Modified: 2011-05-27 04:12 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik 2011-05-08 18:38:26 UTC
The new APC version 3.1.8 seems to have a major problem (in my case with PHP 5.2.17-pl0-gentoo): http://pecl.php.net/bugs/bug.php?id=22687

On my Gentoo box the same problem happens with the new APC. PHP Scripts are broken with errors like:

 Fatal error: main() [function.require]: Failed opening required 'filename.php' (include_path='.:') in on line 429

I think a patch is required.

Reproducible: Always

Steps to Reproduce:
1. Install Wordpress and don't edit /etc/php/cgi-php5.2/ext-active/apc.ini
2. Click a Frontend Page
3. Click the same Frontend page again
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2011-05-08 20:45:18 UTC
Please post your `emerge --info' output too.
Comment 2 Ole Markus With (RETIRED) gentoo-dev 2011-05-09 06:30:26 UTC
Thank you for reporting.

I'll pay some attention to that bug and see what the devs decide. I'll hold of 3.1.8 stabilisation until then.
Comment 3 Ole Markus With (RETIRED) gentoo-dev 2011-05-15 11:22:08 UTC
This should have been fixed in 3.1.9. Could you test and confirm this?
Comment 4 Dominik 2011-05-15 12:55:18 UTC
Yes the bug seems to be gone. Good work.
With 3.1.9 I have no problems with my Wordpress installation.
Comment 5 Hans Nieser 2011-05-25 17:35:02 UTC
I'm not sure if this bug has been fixed in 3.1.9. Today I noticed numerous PHP applications were broken, but surprisingly only after subsequent page refreshes, the first load right after starting apache always worked.

My apache log was filled with PHP errors like:

PHP Fatal error:  require_once(): Failed opening required 'config.php' (include_path='.:/usr/share/php5:/usr/share/php') in \xa0\xbc\x1c\x02 on line 3

Which made no sense since config.php was definitely in the include_path. I was actually able to workaround the problem by specifying the include paths inside included files to be relative to the 'outer' php script (i.e. that did the first include). However this has never been neccesary before and I still have numerous broken PHP applications :/
Comment 6 Ole Markus With (RETIRED) gentoo-dev 2011-05-26 13:56:00 UTC
(In reply to comment #5)
> I'm not sure if this bug has been fixed in 3.1.9. Today I noticed numerous PHP
> applications were broken, but surprisingly only after subsequent page
> refreshes, the first load right after starting apache always worked.
> 
> My apache log was filled with PHP errors like:
> 
> PHP Fatal error:  require_once(): Failed opening required 'config.php'
> (include_path='.:/usr/share/php5:/usr/share/php') in \xa0\xbc\x1c\x02 on line 3
> 
> Which made no sense since config.php was definitely in the include_path. I was
> actually able to workaround the problem by specifying the include paths inside
> included files to be relative to the 'outer' php script (i.e. that did the
> first include). However this has never been neccesary before and I still have
> numerous broken PHP applications :/

I am not quite sure I follow you there. Include paths always have to be defined relative to the script called by apache. If you want it to be relative to another included file you need to use __DIR__ as a part of the include statement.
Comment 7 Hans Nieser 2011-05-27 04:12:49 UTC
(In reply to comment #6)
> I am not quite sure I follow you there. Include paths always have to be defined
> relative to the script called by apache. If you want it to be relative to
> another included file you need to use __DIR__ as a part of the include
> statement.

Hrm I think I may not have expressed myself very clearly there, basically this is my project structure:

lib/config.php
lib/common.php
index.php

Here index.php does "require('lib/common.php')", and lib/common.php does "require('config.php')". This should work as include()/require() will lookup scripts in the currently calling script's directory if it can't find it in the include_path (or in the php manual's wording: "If the file isn't found in the include_path, include() will finally check in the calling script's own directory and the current working directory before failing." - I'm assuming the require() behaviour is the same)

I admit it is probably a bad practice to do it like this, and in new projects I do it differently, but I am hosting a number of old PHP projects that have done it like this for years and they are now all broken with APC :/ I think it's especially telling that they all do work on the first load (i.e. when APC caching may not be in effect yet), but fail on subsequent ones. The random binary data in my log worries me too, but perhaps that is normal for APC cached scripts