Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Ok this is probably just me not knowing enough about php but here it goes.

I'm on Ubuntu Hardy. I have a custom compiled version of PHP which I have compiled with these parameters.

./configure
--enable-soap
--with-zlib
--with-mysql
--with-apxs2=[correct path]
--with-config-file-path=[correct path]
--with-mysqli
--with-curlwrappers
--with-curl
--with-mcrypt

I have used the command pecl install pecl_http to install the http.so extension. It is in the correct module directory for my php.ini. My php.ini is loading and I can change things within the ini and effect php. I have included the extension=http.so line in my php.ini.

That worked fine. Until I added these compilation options in order to add imap

--with-openssl
--with-kerberos
--with-imap
--with-imap-ssl

Which failed because I needed the c-client library which I fixed by apt-get install libc-client-dev After which php compiles fine and I have working imap support, woo.

HOWEVER, now all my calls to HttpRequest which is part of the pecl_http extention in http.so result in Fatal error: Class 'HttpRequest' not found errors. I figure the http.so module is no longer loading for one reason or another but I cannot find any errors showing the reason.

You might say "Have you tried undoing the new imap setup?" To which I will answer. Yes I have. I directly undid all my config changes and uninstalled the c-client library and I still can't get it to work. I thought that's weird... I have made no changes that would have resulted in this issue. After looking at that I have also discovered that not only is the http extension no longer loading but all my extensions loaded via php.ini are no longer loading.

Can someone at least give me some further debugging steps? So far I have tried enabling all errors including startup errors in my php.ini which works for other errors, but I'm not seeing any startup errors either on command line or via apache. And yet again the php.ini appears to be being parsed given that if I run php_info() I get settings that are in the php.ini.

Edit it appears that only some of the php.ini settings are being listened to. Is there a way to test my php.ini?

Edit Edit It appears I am mistaken again and the php.ini is not being loaded at all any longer. However, If I run php_info() I get that it's looking for my php.ini in the correct location.

Edit Edit Edit My config is at the config file path location below but it says no config file loaded. WTF Permission issue? It is currently 644 so everyone should be able to read it if not write it. I tried making it 777 and that didn't work.

Configuration File (php.ini) Path   /etc/php.ini
Loaded Configuration File   (none)

Edit Edit Edit Edit By loading the ini on the command line using the -c command I am able to run my files and using -m shows that my modules load So nothing is wrong with the php.ini

Edit Edit Edit Edit Edit I have had it pointed out to me that my ini directory config should be a path to find the php.ini file in not the file itself. To this end I have tried settings /etc,/etc/, and letting php set the default directory then moving my ini file into that directory. All fail :(

Edit Edit Edit Edit Edit Edit Further info, command line run of php --ini and ls of dir it points at in the php settings. Also run with -c option on command line where the run succeeds and not when i don't include -c

j@j:/usr/local/lib$ php -ini | grep Configuration
Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => (none)
Configuration
j@j:/usr/local/lib$ ls /usr/local/lib
php  php.ini  python2.5  site_ruby
j@j:/usr/local/lib$ php -c /usr/local/lib/php.ini /var/www/toolbelt/test.php
j@j:/usr/local/lib$ php /var/www/toolbelt/test.php

Fatal error: Class 'HttpRequest' not found in /var/www/toolbelt/test.php on line 7
jonathan@jonathan:/usr/local/lib$

Edit Edit Edit Edit Edit Edit Edit Further info. Utilizing the strace method shown below I tested to see if there were any attempts to open the ini file made in the loading of php. There were not

j@j:/usr/local/lib$ sudo strace  -e trace=open php -ini 2>&1 |grep  php.ini
Configuration File (php.ini) Path => /usr/local/lib
j@j:/usr/local/lib$ sudo strace  -e trace=open php -ini 2>&1 |grep  /usr/local/lib
Configuration File (php.ini) Path => /usr/local/lib
extension_dir => /usr/local/lib/php/extensions/no-debug-non-zts-20060613 => /usr/local/lib/php/extensions/no-debug-non-zts-20060613
include_path => .:/usr/local/lib/php => .:/usr/local/lib/php
share|improve this question
1  
which location you put in --with-config-file-path ? –  HD. Feb 9 '11 at 22:56
    
@HD The location shown in Edit Edit Edit /etc/php.ini which is the location at which it is currently located and has 644 permissions. –  Jonathan Park Feb 9 '11 at 23:01
1  
Looking at my servers the value of "Configuration File (php.ini) Path" is /etc, just the directory not the full path. –  HD. Feb 9 '11 at 23:26
1  
Is phpinfo showing the same values? Are your running phpinfo using the web server or using the command line php? –  HD. Feb 9 '11 at 23:38
1  
Before you started building your own, you removed all the existing Ubuntu PHP packages so there would be no conflicts or confusion right? –  Zoredache Feb 9 '11 at 23:50
show 3 more comments

2 Answers

Check the value for the "--with-config-file-path=" option. It should be /etc not /etc/php.ini. It seems that Apache is trying to load /etc/php.ini/php.ini and that's why doesn't find the file.

If this doesn't work, you could strace to check which files are opened by php:

strace -f -e trace=open php --ini

The answer will help you to find out where is php looking for php.ini files. This is the output in one of my servers:

10833 open("/usr/bin/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
10833 open("/etc/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
10833 open("/usr/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
10833 open("/etc/php.ini", O_RDONLY)    = 3
share|improve this answer
    
Good answer however I have tried this and it does not seem to be the answer. Refer to edits for more info. –  Jonathan Park Feb 9 '11 at 23:43
    
This is very useful and I found the same thing in a previous post on stack overflow which I was just trying when you answered this... Sadly it doesn't help me given when I run this strace "-e trace=open php -ini 2>&1 |grep php.ini" it never tries to access php.ini at all. It fails accessing some other library files but it looks like it's just mass checking for the existence of libraries. –  Jonathan Park Feb 10 '11 at 0:11
1  
Really weird, my strace doesn't fail checking any libraries before try to load php.ini even if this is a non existent file. Maybe you could compare with the results of strace using the -c /usr/local/lib/php.ini option. –  HD. Feb 10 '11 at 0:16
    
Perhaps this is the right path then... If php.ini does not exist in the directory to you at least get a failed to open line when it looks? –  Jonathan Park Feb 10 '11 at 0:18
1  
Yes: open("/etc/aaa/php.ini/php.ini", O_RDONLY) = -1 ENOENT (No such file or directory) –  HD. Feb 10 '11 at 0:20
show 1 more comment
up vote 1 down vote accepted

Ok hopefully this will prevent someone else from banging their head against a wall for hours.

I have found my own solution in clean building my php. It turns out that you can alter the with-config-file-path option and have it alter the path that shows up in the phpinfo() and php -ini output. HOWEVER, if you don't clean your build the place where the setting actually gets used does not get rebuilt and will f up your build.

Note to self: always clean your build. I knew this before but got thrown off by the fact that the rebuild does in fact change what php tells me the directory is.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.