php.ini file not being read

Cannot get my php.ini file to be read.
Running freebsd5.3 with apache2.0.53 with php5.
php5 loades as a module.
The server is runing fine with all sites working well. And the php scripts are being read fine as well. In fact everything is working fine.
But when I do changes in the php.ini file none of the work.
Have looked at phpinfo path= /usr/local/php5 so php.ini is not being read. have put php.ini file in the /usr/local/php5 but it is still not being read.
also chmod the php.ini to 777 and still not being read.
Also tried to put the php.ini file in other locations like /etc and /usr/local/lib but no luck

I am lost here please help

thanks

Recommended Answers

All 8 Replies

This may be a stupid question, but, you do know that with PHP as an Apache module, you need to restart Apache (httpd) to see your php.ini changes?

Thank you for your email.
Yes I am aware I need to restarted apache after any changes to apply them.
Yes I have restarted apache probably more times than neccessary.
thanks for your help

You say "php.ini is not being read". But, the PHP module in Apache will not start unless it's reading it's ini file. So may I suggest one of two things.

1. The php.ini file you are editing is not the one being used by Apache. To test this, rename your php.ini file to php.bad or something. Then restart Apache and see if you get errors or if your PHP pages stop working. If it still works, you need to locate the ini file actually being used, and make your changes there.

2. There is a difference between what you think your change should do, and the reality of how your change affects the service. Can you provide some details on one simple change that is not working the way you expect? Maybe others can test with their config.

thank you for your reply.
1] the changes I do which do not respond are display error = off/on. Have tried it on my localhost host. works fine.
Also works fine on my server when I have a PHPIniDir line in my apache config. But with out the PHPIniDir line it does not work. However my server been working fine up to now. Only when I went to make changes to the php.ini file did I realised that it was not being read. I have deleted all php.ini files present by doing a search for them and only one is left so far.
phpinfo file [information from phpinfo file]
Configuration File (php.ini) Path /usr/local/php5 [in this path i have made sure there is a php.ini file]

'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-mysql' '--prefix=/usr/local/php5' '--disable-cgi' '--enable-force-cgi-redirect' '--with-config-file-path=/usr/local/php5'

2] as regard the changes I am expect of course errors should not be displayed. I doubt the will be any misinterpertation in that result. I have uploaded a file which gives a php prase error. and the error is still being displayed though I have set php.ini not to display errors.

Also strated a thread in another form and some info from there. Thanks for your help
http://www.phpbuilder.com/board/showthread.php?s=&postid=10634466#post10634466

Put the "PHPIniDir usr/local/php5" line into http.conf............................................
...................the PHPIniDir is that line normally supposed to be there specifying where php.ini is present. Or am I entering now as I have not configure correctly. Like I said when I did use the phpinidir line the php.ini is recoginsed. Just trying to learn. Thanks for your help greatly appreciated.

the site has been runing fine so far................wondering what php.ini file has been used up to now was it the php.ini-recommended or that dist one. made a few changes inthem as well but did not do any difference.

any ideas as to why my mail function stops working.
phpinfo give the below information
sendmail_path [local value]/usr/sbin/sendmail -t -i [master value]/usr/sbin/sendmail -t -i

Thanks

I'll look at this some more, but did you just say it works fine if you specificy the php ini file in Apache's config using the PHPIniDir directive? Then why not let that be your solution?! I understand wanting to know why, but there is a LOT of stuff about a lot of services/configurations that I never fully understand--I just know I figured out enough to get it working and moved on. Placing a PHPIniDir directive in the Apache conf is not a "messy hack" or anything, so I would not feel bad using it...problem solved.

Hi,
Thank you for your reply.
Well the problem is only half solved. As though now i can get my php.ini file to be read the mail function in php stops working. which is very important to my site .
Wondering why the mail function stops working.
Thus need to understand why I need to use the phpinidir and what php.ini file was being used before to solve my mail function problem.
I use sendmail. have specified the correct path in the php.ini but still no luck.
Yes I do restarted apache everytime :D

Well, the pattern seems clear that without the Apache directive, your php.ini file is NOT being used. Therefore, any settings in it are not being used. When you use the directive, you can tell your php.ini is being used, but PHP mail stops working. This definitely seems to point to something in the php.ini file that is breaking email functionality. Take a closer look at the mail settins in the php.ini file---maybe comment them all out since it worked without them before. I'm not really sure if this will help you, or if I'm messing you up more.

Similar behavior here: Apache php functionality stops working unless PHPIniDir directive is in, but doesn't care where the directive is pointing... Whether it's pointing to Windows folder or PHP5 folder (where my only php.ini copy resides), it wouldn't respond to any changes made to the .ini file. It's frustrating as hell! And php_ini_loaded_file says nothing's loaded!

I know it's been a while :) But that's one more reason for me to hope that you have somehow solved it by now.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.