php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #41462 config-scan-dir and config-path will load the same php.ini twice.
Submitted: 2007-05-22 15:32 UTC Modified: 2007-05-23 16:51 UTC
From: jean dot bruenn at ip-minds dot de Assigned:
Status: Not a bug Package: *Configuration Issues
PHP Version: 5.2.2 OS: Linux (2.6.x Kernel) SMP
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jean dot bruenn at ip-minds dot de
New email:
PHP Version: OS:

 

 [2007-05-22 15:32 UTC] jean dot bruenn at ip-minds dot de 
Description:
------------
btw. it does not matter WHICH php Version - i had this problems with older version of php5 too.

i was wondering why i get errors cause of extensions. It meant it can't load them 'again'. That was no problem at all, i just ignored this messages, now i tried to install the zend optimizer (hey.. it's not a zend-related problem!) it gives a fatal error cause it can't load the extension twice. It seems that many ppl having such problems - it comes when u use --with-config-scan-dir and --with-config-path (both options) and both are pointing to the same directory.

Reproduce code:
---------------
Well.. just create a folder to store the php.ini - for example "testphp" in /etc now recompile php with: '--with-layout=GNU' '--with-config-file-path=/etc/testphp' '--with-config-file-scan-dir=/etc/testphp' now put your php.ini into this directory and put some extensions into it, for example xcache or the zend optimizer or apc, or whatever you want. when you go to your source directory and type "make test" you will see 1. (see at actual result) - and it will give you errors cause of some extensions (zend optimizer will give a fatal one and make test is stopping)

i recompiled it then with _one_ of these settings - see 1. in expected results - now it's working, strange eh?

So.. is it a bug or a feature? ;)

Expected result:
----------------
1. (thats how it looks if you use one of these configure settings)

INI actual  : /etc/testphp/php.ini
More .INIs  : 




Actual result:
--------------
1. (thats how it look if you use both configure settings)

INI actual  : /etc/testphp/php.ini
More .INIs  : /etc/testphp/php.ini

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-22 17:30 UTC] johannes@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.
 [2007-05-23 16:51 UTC] jean dot bruenn at ip-minds dot de 
So, it's not a bug, if it's loading the php.ini twice? ;-)

I mean, i understand that it's not a real bug - but i think this should be changed. Cause if you look in your favorite search engine for such problems (and related) you'll see that many ppl having this problem.

Anyway. Simply wanted to report it, now you have it, do what u want with it ;-)
 [2010-09-02 02:15 UTC] dotpointer at gmail dot com 
Stumbled upon this problem recently. Maybe this is not named "bug" specifically, but a problem it is.

It took time to understand why PHP CLI complained about already loaded modules.

Something - even a warning when running ./configure would be in place.

Best (I guess) would be that php.ini is avoided when trying to load additional ini-files.

Say I am so stupid I compile PHP with these paramters (which was what I did lately...):
--with-config-file-scan-dir=/etc/php
--with-config-file-path=/etc/php
<plus some shared modules>

Then I have to choose between not being able to load the shared modules at all, or to get an error in the CLI, because the INI-file is being read twice, which disables the functionality.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Fri Feb 06 06:00:01 2026 UTC