php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22174 php.ini being ignored - only in release version
Submitted: 2003-02-11 14:15 UTC Modified: 2003-02-18 04:23 UTC
From: marcus at synchromedia dot co dot uk Assigned:
Status: Closed Package: PHP options/info functions
PHP Version: 4.3.2-dev OS: OpenBSD 3.1-stable
Private report: No CVE-ID: None
 [2003-02-11 14:15 UTC] marcus at synchromedia dot co dot uk
This problem seems to take many forms, as evidenced by the bug database, but from all the entries I have read, none seems quite like what I'm seeing.

I've been using 4.3 from CVS since about last June, and set up my php.ini around then, and I have not really touched it since (not the problem). I've stayed with CVS versions ever since, until today. I started having a compilation problem with the cvs version (Separate problem), but I still needed to rebuild PHP so I grabbed the release 4.3.0. This compiled (using the same configure I've been using all along) with no problems so I installed it and got file not found errors all over. phpinfo reveals that everything is at defaults (include_path at default value was causing my errors), i.e. php.ini is being ignored. I recompiled several times specifying many different locations for php.ini, but none worked.

So now it looks like maybe a permissions problem, Except that the php.ini is the same file that has been working for many months with cvs versions up until yesterday - this is the first time I've tried using a release version. Whatever, all permissions look fine - the www user has no trouble reading the file.

I thought perhaps the format or content of the ini file had changed, so I built a new one with my settings in from php.ini-recommended. Made no difference, but was probably a good idea anyway.

Eventually I found the bug report about php preferring /php.ini over the compiled in location, so I copied my old php.ini there and it did indeed pick it up (a temporary workaround), So now I know there's nothing wrong with what's in either my old or new php.ini files (I don't seem to be seeing the current open bug about php.ini based on recommended not working).

So the only remaining variable is that I'm using 4.3.0 release, and not a CVS version. Everything else is identical. I can only surmise that it must be a release version bug. I would like to confirm this by compiling a CVS version and have it work, but as I mentioned, it's not compiling for me right now, so I can't test that.

Just for good measure, here's my configure:
./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --enable-pcntl --with-config-file-path=/var/www/conf --enable-mbstring --with-pear=/usr/local/lib/php --enable-bcmath --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local

Extracts from phpinfo:
With /php.ini:
Configuration File (php.ini) Path /php.ini

Without /php.ini, (ini in specified place)
Configuration File (php.ini) Path /var/www/conf/

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-11 15:18 UTC] sniper@php.net
I upgraded the libtool version in CVS and we now require
libtool 1.4.3. Just install that and the compile problems 
should be gone..(and update your cvs checkout since I just fixed some other issue that came with the libtool upgrade)

About the php.ini location..you're sure the bug is not present in the PHP_4_3 branch? 

 [2003-02-11 16:46 UTC] marcus at synchromedia dot co dot uk
I'm already using libtool 1.4.3, so it's not that.

I last rebuilt PHP from CVS yesterday morning and it was all ok. Up until switching to 4.3 release, I had never seen a problem with my ini file. Very strange I know...

The compile problem seems to be something to do with gm4? It dumps lots of pages relating to bison? I'll do a more accurate bug report if it's still there tomorrow.
 [2003-02-11 17:43 UTC] iliaa@php.net
If you have an strace utility try to strace the cli binary and see if it tries to open any ini files and if it successful openning any of them.
This can be done using the following command:
strace php -h 2>&1 | grep ".ini"
 [2003-02-11 20:37 UTC] sniper@php.net
Assuming you're using the PHP_4_3 branch, updated version.

Did you mean 'm4' outputs errors? Check your m4 version,
and if it's anything else than 1.4, update it.
If the error comes within configure, you might have
to rebuild your autoconf also with the new m4..

 [2003-02-12 04:24 UTC] marcus at synchromedia dot co dot uk
Unfortunately there doesn't seem to be a working strace for OpenBSD, I can't get it to compile (reports unsupported OS) and it won't compile as FreeBSD on my system.
PHP CLI works correctly if I specify -c and point to the ini file, but it too does not pick up the ini from the compiled-in location (and as noted elsewhere, it doesn't look in /php.ini either).
Probably best to leave this bug open/feedback until I can get the CVS version working again (It's still broken for me today, so I'm reporting it now).
 [2003-02-12 22:07 UTC] sniper@php.net
Please try using this CVS snapshot:

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


(does anything work in openbsd? :)

 [2003-02-18 04:23 UTC] marcus at synchromedia dot co dot uk
Now that I have finally got PHP-cvs compiling again, I'm happy to report that it's picking up my php.ini from the compiled in location. 4.3.0-release still does not, so I guess whatever the probem is, it's been fixed in CVS.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 08:01:27 2024 UTC