Does PHP cgi have its own set of .ini files that differ from PHP cli?

Question

The server is:

CentOS Linux release 7.4.1708 (Core) , 3.10.0-693.5.2.el7.x86_64
PHP 5.4.16 (cli) (built: Nov 15 2017 16:33:54)

I wasn't able to get PHP SOAP to work without an error from web pages, although the test I did worked fine at the command line in Linux for PHP cli. After a lot of searching I found a suggest to add the following to the /etc/php.ini file:

extension=soap.so

This make the web pages doing the SOAP requests work fine, however, the PHP CLI is producing this error:

PHP Warning:  Module 'soap' already loaded in Unknown on line 0

I get the above message even doing a 'php -v' at the command line.

If the soap module is already loaded, why doesn't soap work in web pages for cgi? If it already loaded, where is it already loaded at, and how do I correct this?

# yum list | grep -i soap
php-soap.x86_64                         5.4.16-43.el7_4                @updates 
CGSI-gSOAP.x86_64                       1.3.10-7.el7                   epel     
CGSI-gSOAP-devel.x86_64                 1.3.10-7.el7                   epel     
SOAPpy.noarch                           0.11.6-17.el7                  base     
fence-agents-vmware-soap.x86_64         4.0.11-66.el7_4.3              updates  
glite-lbjp-common-gsoap-plugin.x86_64   3.2.12-7.el7                   epel     
glite-lbjp-common-gsoap-plugin-devel.x86_64
gsoap.x86_64                            2.8.16-9.el7                   epel     
gsoap-devel.x86_64                      2.8.16-9.el7                   epel     
gsoap-doc.noarch                        2.8.16-9.el7                   epel     
perl-POE-Component-Server-SOAP.noarch   1.14-12.el7                    epel     
perl-SOAP-Lite.noarch                   1.10-1.el7                     epel     
perl-SOAP-WSDL.noarch                   3.003-6.el7                    epel     
perl-SOAP-WSDL-Apache.noarch            3.003-6.el7                    epel     
perl-SOAP-WSDL-examples.noarch          3.003-6.el7                    epel     
php-ZendFramework-Soap.noarch           1.12.20-1.el7                  epel     
php-ZendFramework2-Soap.noarch          2.4.11-1.el7                   epel     
php-pear-SOAP.noarch                    0.13.0-5.el7                   epel     
qtsoap.x86_64                           2.7-9.el7                      epel     
qtsoap-devel.x86_64                     2.7-9.el7                      epel     

This existed as part of the 'yum install php-soap':

# cat /etc/php.d/soap.ini
; Enable soap extension module
extension=soap.so

It seems like this should be left alone. If I remove the extension=soap.so from the /etc/php.ini, the warning error message at the command line goes away, but it breaks the php soap related web pages.

Further, I don't understand why SOAP for the php web pages isn't simply installed and configured with the rest of the yum installations for php and soap.

Are their .ini or other configuration files that needed to be changed to add extension=soap.so? If so, where are those files?

I ran the phpinfo program through the web browser and at the command line and got the same results for the path:

Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d

The exception is that from the web browser for "Server API" it is: Apache 2.0 Handler.

When I run this:

php -i | grep -i soap

This is the output:

PHP Warning:  Module 'soap' already loaded in Unknown on line 0
/etc/php.d/soap.ini,
PHP Warning:  Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Unknown on line 0
soap
Soap Client => enabled
Soap Server => enabled
soap.wsdl_cache => 1 => 1
soap.wsdl_cache_dir => /tmp => /tmp
soap.wsdl_cache_enabled => 1 => 1
soap.wsdl_cache_limit => 5 => 5
soap.wsdl_cache_ttl => 86400 => 86400

To compare, I created an instance in virtualBox for CentOS 7 and manually installed PHP 7 instead of the PHP 5 that comes with CentOS 7.

PHP 7.0.25 (cli) (built: Oct 27 2017 13:55:11) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

This only has one php.ini file located in /etc/php.ini and with soap.so added to it, it works fine without errors at the command line and phpinfo() run from the server also says it is using the php.ini in /etc. It also mentioned that it is using /etc/php.d, but so what PHP 5. But the directory looks different even though it contains the same soap.ini file's contents, but the file names are different. In the PHP 7 installation they are named 20-soap.ini while in the PHP 5 installation it is named soap.ini.

In PHP 5 if I add soap.so to the /etc/php.ini file, the same that the CGI is apparently using this makes SOAP work for the CGI, but it generates an error at the command line about soap already being loaded.

This might be helpful, I have edited the php.ini to add soap.ini, and done this:

service httpd restart

That causes the CGI to work, and no errors from the command line for PHP, that is, until I reboot the server and then the PHP Warning about soap already being loaded returns.

Where else and how could the PHP cli already have loaded soap.so that it doesn't need it added to the php.ini file? Could this mean that PHP was compiled with soap.so built into it?

Answer 1

The php.ini path can be different for cli and cgi. Test <?php phpinfo(); ?> with cli and cgi to see which path they use.

2nd round

It seems to me that your php cli executable is linked with soap.so that's why it complains when you instruct it in php.ini to load it again. On the other hand your webserver might use php via a shared library that is not linked with soap.so so you need the "extension=soap.so" line in php.ini to load soap.so by dlopen(). The solution could be using a different php.ini for the webserver php library and for the php cli executable as it is usual on Debian based distros. Try to find how you webserver uses the php module. E.g. on Ubuntu 16.04 with apache one can find /usr/lib/apache2/modules/libphp7.0.so. Then compare the linked libs:

ldd $(which php)
ldd /usr/lib/apache2/modules/libphp7.0.so

(Replace the path in the 2nd line with the path of your php module.)

You can use the -c switch at the php command line to specify a different ini file.

php -c /etc/php.cli.ini myprogram.php

Answer 2

The quick answer is YES. Anytime I am troubleshooting php, the very first thing I do is a phpinfo() (or php -i) to verify which one it's using first.

Answer 3

Yes, it's quite normal. In Debian for example:

root@xxxxx:~# ls /etc/php5/
apache2  cgi  cli  conf.d  fpm  mods-available

For example in this case there is a default apache2 php.ini, another for CGI, another for FPM, and the one for CLI. If I were to go into each of these directories, I would find a php.ini for each one.

Answer 4

PHP may read the configuration files differently for the SAPI (server API) and CLI.

If this environment variable is set in your or in the system wide bash profile then PHP will scan directories looking for config files.

PHP_INI_SCAN_DIR=:/etc/php.d

This sounds like what's happening in your case. That environment variable could be set for you but not the apache user.

When you run the CLI, it's reading all the php.ini config files and throwing that warning.

See http://php.net/manual/en/configuration.file.php for more information about how PHP is configured.