php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14401 Wrong include_path from Apache <Directory> config
Submitted: 2001-12-10 08:51 UTC Modified: 2002-11-29 14:32 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: vogel at folz dot de Assigned:
Status: Closed Package: Apache related
PHP Version: 4.3.0-dev OS: Linux i386
Private report: No CVE-ID: None
 [2001-12-10 08:51 UTC] vogel at folz dot de
We have a virtual host here where the include_path varies
per directory.  We configure this in the Apache config
(php as a DSO module) like this:

<Directory /var/www/html/dir1>
  php_value include_path ".:/var/www/html/dir1/lib"
</Directory>
<Directory /var/www/html/dir2>
  php_value include_path ".:/var/www/html/dir2/lib"
</Directory>
(and many more)

We have tried this with many versions of Apache 1.3.x
and php-4.0.x (up to apache-1.3.22 / php-4.1.0RC3) and
all combinations exhibit the same problem:  If there are
two or more concurrent users that access different
directories of this virtual host, one or more of them get
pages with php errors, because the php scripts don't
get the include files they need.  The error messages show
clearly that the include files were searched via a wrong
include_path, i.e. one out of the other <Directory ..>
sections of the same virtual host.

We used both standard Redhat 7.x apache and php RPMs, as
well as self-compiled RPMs based on Redhat's SRPMs, all
with the same result/problem.

If you need more specific information, please ask.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-16 10:59 UTC] vogel at folz dot de
Having looked somewhat deeper into this issue I want to add
that the include path problem seems limited to include files
that get loaded via the auto_prepend_file directive.
Explicit "include" or "require" statements seem to work
as they should.  But please take this with a grain of salt,
because this may be a result of the fact that files with
auto_prepend_file-loaded headers have far more hits than
those with explicit "include"s.
 [2002-02-19 04:18 UTC] vogel at folz dot de
Status update:
o The problem persists with php-4.1.1.
o The problem is _not_ a concurrency, but more like a
  caching problem:  It does happen even with only one
  current user of this server, but only if this user
  requests files from different subdirectories.
o This is the only virtual host where we use varying
  include_paths and we really need auto_prepend_file there,
  so I cannot say if it happens without auto_prepend_file.
  (I haven't had the time to set up a new virtual host for
  testing this.)
o From Feb. 01, 2002 until yesterday (Feb. 18), and with
  php-4.1.1 installed at the end of Jan. 2002, it happens
  in about 25 % of the requests of files where the
  auto_prepend_file feature is active.

 [2002-03-28 05:56 UTC] vogel at folz dot de
This problem is still present with 4.1.2 and gets more and more annoying with every new release.  For some unknown
reason a repeated browser "reload" did help in most cases
with versions before 4.1.2, but now this almost never gets
around the problem.

I've changed Version from 4.1.0 to "4.0.x to 4.1.2" and
Category from "Configuration issue" to"Apache related" now;
maybe I'll get some more response this way (got nothing so
far; are we the only ones in the whole world with such
a setup?!?).

I'm really willing to help to resolve this issue, but I
need some guidance on what the developers need.  Maybe this
problem seems a real corner case to them, but to us it
means that we'll have to split up a service that worked on
a single virtual host with previous php versions (admitted,
not always, but "often enough") into many virtual hosts
with the current version of php (4.1.2).

Please don't get me wrong (I don't want to put pressure on
anybody), I just want to make it clear:  If and when we'll
have converted our setup, then we'll no longer be able to
support anybody tracking down this bug.

I think I've said all the important things: the
include_path use, that it seems to be strongly related to
the auto_prepend_file feature, and that this setup
sometimes does work well and sometimes not, without any
apparent reason for the change of behaviour.

If you have questions about any other details of our setup,
then *please* ask.
 [2002-06-18 05:15 UTC] vogel at folz dot de
Well, it took some time, but this problem now happened even
with version 4.2.1.  4.2.0 and 4.2.1 improved the situation
very much:  It took 20 days after installation of php-4.2.1
until it happened the first time a few days ago, and since
then there are only a few events per day. With late 4.1.x
releases the auto_prepend_file seemed to get unuseable for
us.

Since the first 4.2.1 occurance of the problem, the error
rate increased slowly and is now near 50 % when hitting
files that use the auto_prepend_file feature.  I have to
restart the Apache server now, so that our people can 
access this service again.

Background is still the same: apache-1.3.22 and php as a
DSO module, both self compiled and used in a redhat-7.0
environment, using the redhat spec files for apache
and php.
 [2002-07-10 08:38 UTC] vogel at folz dot de
Upgrading to apache-1.3.26 made it worse again.  Recompiling
the php-4.2.1 module with apache-1.3.26 installed did not
improve the situation.

We have to restart the apache daemon daily to keep the
error rate at a bearable, but still annoying, level.
 [2002-07-16 09:40 UTC] jflemer@php.net
There is another bug w/ include_path (#15374), and a temporary work around was to put this before any include:

ini_set('include_path', ini_get('include_path'));

Though if you have problems with prepend files, there probably isn't any place you could put this where it would get executed in time. =/
 [2002-07-16 14:18 UTC] sniper@php.net
Try this snapshot:

http://snaps.php.net/php4-latest.tar.gz

 [2002-07-17 12:59 UTC] vogel at folz dot de
Well, the php4-200207170000 snapshot (which was in the
php4-latest tarball) does not build as an RPM.  The most
important problem (and the show stopper for now) is
that the pear installation does not honor the INSTALL_ROOT
variable.  This defeats building the RPM as a non-root
user. Please look at the spec file from Redhat's SRPMs
(we use 7.0, 7.1 and 7.2) if you don't know what I mean.

Other problems:
o ext/imap does not build (configure: error: build test
  failed. Please check the config.log for details.
  Looks like a bug in configure: there's no -lc-client
  in the gcc command line in config.log.)
o ext/pgsql does not build (seems fixed in the
  php4-200207170600 snapshot, will try tomorrow).
o DOM support needs libxml version 2.4.14 (says configure), 
  but I have only 2.4.2 and must stay with this, at least
  at the moment.
 [2002-07-17 13:49 UTC] sniper@php.net
Did the include_path issue get solved with the snapshot or not? This is development version, so there might always
be some build problems, etc. 

Can you also explain which part of pear install does not honour INSTALL_ROOT? It works just fine here..

And the imap problem..what was in the config.log? 
It's most likely NOT any bug in configure but some
problem in your system.


 [2002-07-18 10:38 UTC] vogel at folz dot de
When I said "show stopper" I meant "installation failed",
hence I don't know if this fixes the include_path problem.

The IMAP part of configure works half way: It detects that
SSL libraries are needed for c-client, but the build test
fails.  The end of config.log reads:
configure:34926: checking whether SSL libraries are needed for c-client
configure:35086: checking whether IMAP works
configure:35119: gcc -o conftest -O2 -march=i386 -mcpu=i686 -fPIC   -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib conftest.c  -lcrypt -lpam -lgmp -lgd -lttf -lX11 -lXpm -lpng -lz -ljpeg -ldb -lgdbm -lbz2 -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl  -lcrypt 1>&5
/tmp/cc8QGtUw.o: In function `main':
/tmp/cc8QGtUw.o(.text+0x112): undefined reference to `mail_open'
collect2: ld returned 1 exit status
configure: failed program was:
#line 35094 "configure"
#include "confdefs.h"

    void mm_log(void){}
    void mm_dlog(void){}
    void mm_flags(void){}
    void mm_fatal(void){}
    void mm_critical(void){}
    void mm_nocritical(void){}
    void mm_notify(void){}
    void mm_login(void){}
    void mm_diskerror(void){}
    void mm_status(void){}
    void mm_lsub(void){}
    void mm_list(void){}
    void mm_exists(void){}
    void mm_searched(void){}
    void mm_expunged(void){}
    char mail_open();
    int main() {
      mail_open(0,"",0);
      return 0;
    }

See, there's no -lc-client.
I even did a "IMAP_SHARED_LIBADD=-lc-client ; export IMAP_SHARED_LIBADD"
before calling configure and nothing changed.... 

I had various other build problems until I removed the
--disable-rpath option from configure (--disable-rpath was
there for "historical" reasons, read: because redhat used
it in their spec file).

The PEAR installation fails right at it's start:
$ make install INSTALL_ROOT=/var/tmp/php-root
[/bin/sh libtool command omitted for brevity]
Installing PHP SAPI module
Installing shared extensions:     /var/tmp/php-root/usr/lib/php4/
Installing PHP CLI binary:        /var/tmp/php-root/usr/bin/
Installing PEAR environment:      /var/tmp/php-root/usr/share/pear/

Warning: SAFE MODE Restriction in effect.  The script whose uid is 503 is not allowed to access /usr/share owned by uid 0 in /home/vogel/rpm/BUILD/php4-200207170600/pear/System.php on line 235

This last message is repeated _many_ times, with some
"Warning: version_compare() expects parameter 2" messages
interspersed.

I can reproduce this in various ways (i. e. building using
rpm or doing the same "by hand"; changing configure options
did not help in any way).

If you want to reproduce: environment is redhat linux 7.0
with all relevant updates from redhat installed.  I don't
want to build with a newer redhat release, because the
target server, where the binary will get installed finally,
has redhat 7.0, too (and -- you guess it -- I cannot update
to a newer release because that's a "production" machine).

And yes, ext/pgsql in snapshot 200207170600 builds.

If you're interested, I can send you a complete log of the
rpm build via email.  I don't want to include it here
because of it's size (over 500 kByte).
 [2002-07-18 12:53 UTC] vogel at folz dot de
I forgot two things:
o The above extract from config.log was created with
  snapshot 200207170600.
o In response to your comment "... some problem in your
  system" I updated the bash package to that of redhat-7.1,
  but without any effect. The bash package of redhat-7.2
  has more bugs fixed, but does not fit into a redhat-7.0
  system (incompatible changes).

After some more debugging in the last four hours I'm
pretty sure that it is _not_ a problem of our redhat
installation.

But what I did not find: How is "make" supposed to pass
the INSTALL_ROOT variable on to the php scripts that it
executes when the install-pear-installer and
install-pear-packages targets are called?
 [2002-07-18 13:24 UTC] sniper@php.net
Please, only ONE BUG per report, thank you.

Does the latest snapshot fix the include_path problem or not? (I'm not interested if it doesn't build with all your configure options right now..)

 [2002-07-18 13:39 UTC] vogel at folz dot de
Hmpf.  I can't tell you if the include_path issue is fixed
because I cannot even install this %*$# snapshot release.

Is this clear enough?

Our server machines are stripped down and don't have the
tools you need to build programs and RPM packages.  So we
_must_ build a RPM package on one of our development
machines, and if that RPM package passes some tests, we
can install this on our servers.  Copying the server
setup to some test server on a development machine does
not really help to be sure, because it would be difficult
to simulate the work load of the "real" server.
 [2002-07-23 12:31 UTC] vogel at folz dot de
A short note to confirm the obvious: release 4.2.2 did
_not_ fix this problem.  It took about 24 hours after
the upgrade until it happened for the first time.
 [2002-09-23 11:52 UTC] vogel at folz dot de
Well, I had hoped that the bug fix for the Apache XbitHack
would also fix our auto_prepend_file+include_path problem,
but it certainly does not.

In other words: 4.2.3 has _still_ this problem of wrong
include_path's for files loaded via auto_prepend_file.
 [2002-10-27 22:35 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-11-10 18:27 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2002-11-11 13:10 UTC] vogel at folz dot de
Well, as reported earlier, I need a working RPM installation,
which means that bug #18568 has to be fixed, too, which it's
not, as of snapshot 200211101739.
 [2002-11-24 23:15 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

The previously mentioned bug, #18568 has been fixed.
 [2002-11-29 14:32 UTC] vogel at folz dot de
OK, we have the STABLE-200211261030 snapshot up and running
for over three days now, without any problems so far.

Sadly, there's nothing in the Changelog which refers to
this bug (at least I did not notice something similar).
So I must rely on my experience, which says that we must
wait for some days/weeks more, before we can be reasonably
sure that this bug is really gone (remember: with 4.2.1 it
took nearly 3 weeks until it happened for the first time
after upgrade).

Nevertheless, I'm setting this to "Closed" now, but will
re-open if the problem should occur once more.
 [2003-01-16 11:07 UTC] moderator at blackpeeps dot com
Was this issue ever fixed? 

I just upgraded to PHP 4.3.0 from 4.1.2 

I have a php script that I was running on virtual domain (site3) which has a require_once function to bring in source from a config.php file located in the server path of another virutal domain (site2) on same server.  On 4.1.2 this all worked fine.

The config.php has several include functions which include other php source files from site2. But after the uprade, the includes are bombing on the script being from form domain/path site3. 

Is there something in the php.ini file that may have changed that no longer allows a given sript to include files across virtual domain paths?
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jun 28 17:05:44 2022 UTC