php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #6230 php.ini is not being read
Submitted: 2000-08-18 00:57 UTC Modified: 2000-09-05 21:51 UTC
From: vaughan at ucla dot edu Assigned:
Status: Closed Package: Installation problem
PHP Version: 4.0 Latest CVS (18/08/2000) OS: Linux 2.2.14
Private report: No CVE-ID: None
 [2000-08-18 00:57 UTC] vaughan at ucla dot edu
In order to deal with bug # 6157, I followed the advice and downloaded and compiled Version 4.0.2-dev.    --with-mysql --with-apxs --enable-track-vars --enable-trans-sid  --with-config-file-path=/etc/php4/apache

Compiled ok.  Picks up where the config file (php.ini) should be, but certainly does not read that file, or if it does then it makes none of the changes I have put in (eg. that /phpsessions be the sessions directory).  Permissions on the file are ok.  Nothing in the Apache error log.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-08-18 05:45 UTC] hholzgra@php.net
could you please check with 'ls -la php.ini'
that the file is really read ... ?
 [2000-08-18 12:17 UTC] vaughan at ucla dot edu
here it is:

-rw-r--r--    1 www-data www-data    14981 Aug 15 08:28 /etc/php4/apache/php.ini

The owner used to be root, but I changed it to see if that would help. I restart apache with apachectl whenever I make a change.  nothing shows up in phpinfo() as changed.

Apache/1.3.12 (Unix)
 Debian/GNU 
PHP/4.0.2-dev
 [2000-08-23 05:07 UTC] hholzgra@php.net
i had a similar problem yesterday (bug #6302)
and found out that php.ini worked as expected
when i started apache in single-process mode
with option -X for debugging reasons but that
it totaly ignored php.ini in its normal
multiprocess mode of operation

could you please try if you get the same effect
when starting apache with 'httpd -X' ?
 [2000-08-23 14:06 UTC] vaughan at ucla dot edu
I used /usr/sbin/apache -X to restart the httpd daemon as you suggested.  PHP still fails to read the php.ini file.  Nothing of interest in the error.log.
 [2000-08-23 14:14 UTC] hholzgra@php.net
the '-X' thing was related to something else 
that has been solved (see #6302)

but your case is different so lets get back
to the 'ls -la' story

you should do a 'ls -la' before and after
you start apache 

if php.ini is beeing read the date and time
should change as the 'a' option tells ls to
show the last access time instead of the
modification time

if it doesn't change you shoud 'cat php.ini'
and check the output of 'ls -la php-ini'
again

if it still doesn't change then access time
tracking is off for your filesystem, if it
does then you can be sure that the webserver
doesn't read the file ...
 [2000-08-23 14:40 UTC] vaughan at ucla dot edu
Looks like you've identified the problem!  Any ideas about where to go from here?

ls -la /etc/php4/apache/php.ini

-rw-r--r--    1 www-data www-data    14981 Aug 15 08:28 /etc/php4/apache/php.ini

 apachectl restart

ls -la /etc/php4/apache/php.ini
-rw-r--r--    1 www-data www-data    14981 Aug 15 08:28 
/etc/php4/apache/php.ini

# date
Wed Aug 23 11:34:00 PDT 2000

# cat /etc/php4/apache/php.ini

# ls -la /etc/php4/apache/php.ini
-rw-r--r--    1 www-data www-data    14981 Aug 15 08:28 
/etc/php4/apache/php.ini
 [2000-09-04 16:55 UTC] sniper@php.net
So, what is the situation now? Have you tried CVS lately? 
Is it working now or what?

--Jani
 [2000-09-05 13:29 UTC] vaughan at ucla dot edu
Jani,

Thanks for following up.  A post I made seems not to have been committed to your database.

I checked with a linux advisor, who pointed out that there are three file times we need to be aware of: creation time, modification time and access time.  'ls -la'  gives us creation time.  'ls -lu' gives us access time, which is what we want.  But the access time associated with php.ini does  change when I stop and start apache.  

That was with the 2000817 CVS,

With today's CVS I just get the following errors when I try to load apache

PHP Warning:  Unable to load dynamic library '/usr/lib/php4/apache/mysql.so' - /usr/lib/php4/apache/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
Failed loading /usr/lib/phplib/Zend/ZendOptimizer.so:  /usr/lib/phplib/Zend/ZendOptimizer.so: undefined symbol: zend_v_compile_files

Apache does load, however, and reads the php.ini file, picking up the relevant changes (eg to session settings).  

Now I at least have one problem solved, with two more to replace it :-)
 [2000-09-05 19:58 UTC] sniper@php.net
Does this file exist: /usr/lib/php4/apache/mysql.so
And have you tried without Zend optimizer?

There have been done many changes in the CVS today. I suggest you
wait 1-2 days before doing cvs update.  And report back how you problem
evolves..

--Jani
 [2000-09-05 21:27 UTC] vaughan at ucla dot edu
since the php.ini file is now being read, I suppose we can close this bug?

I put a new version of ZendOptimizer on and it solved the startup problem with that.  

mysql.so is nowhere on the system 


 [2000-09-05 21:51 UTC] sniper@php.net
Closed by user request. 

--Jani

 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Sat Aug 02 07:00:03 2025 UTC