I've compiled the php 7.4 for centos 7 server. I also have an apache installed 2.4.

The problem is that I have no clue what to do next to make it work. Previously I had 2 sites working with the official package, so the configuration should be fine - the only thing which is changed is the php - completely. Why do I need this compiled php and why I dont like the package? It's because I need ZTS support for the php, which isn't in the precompiled version, and it's necessary for parallel support(multithreading)

On Windows this whole compiling the php and make it working was a joke comparing to this(it was like 1 day with 0 knowledge). I just configured the compiler, compiled, replaced the php folder in the webserver and it was working perfectly and every single tests in the sites were passing as well.

On the other hand in centos, I compiled the php, and some extensions + extra packages to make it work. When I check the modules with php -m, all of them looks good. The only issue is that the webserver is not loading the sites anymore. Also this is the 4th day I'm suffering with it - there is always a new type of problem.

After I compiled the php I replaced the binary file in the PHP CLI binary. Actually I have no idea if it's a correct thing to do or not, because I can't find any information about this part, because most of the descriptions end where you run the make install command, or do some little bit of extra.

So what I need is some guidance from someone who can explain to me what needs to be done and why should that be done.

There is also php-fpm compiled in the binary, but I dont know if it has an effect on it.

I also have no idea how to debug this situation. I can reach the server, and I can see the default apache testing page, so as expected it didn't changed a bit, and working.

So what I would like to know is some kind of clue about how to figure this out, or some explanation about what files should be placed where and why?


Update after the suggestions:

I went through on the whole process again - created a new volume from the snapshot I made before I started to work on this, and restarted from zero. The today's progress is that after that even the modules weren't loading - zend_opcache and the mongodb. Now after running the sudo make install cmd, it's clearly says where to put the modules: /usr/local/php7/lib/php/extensions/no-debug-zts-20190902/ and a description I found also says where to modify what ini file, to make it work: https://shaunfreeman.name/blog/compiling-php-7-on-centos

sudo vim /usr/local/php7/etc/conf.d/modules.ini 

But this doesn't do anything anymore, like before. There is also a php.ini file which is suggested to be copied:

sudo cp -v ./php.ini-production /usr/local/php7/lib/php.ini

But modifying that php.ini file to dinamically load the extensions also does nothing, so I guess the php which should use that ini file can't see the file at all. So I checked whereis php and it says: php: /usr/share/php /usr/local/php7/bin/php

The second one is what I put into the $PATH variable, but I think the load order is to load the first one. This was created by the first make install, and this php file is not changing when I run it again. Maybe it has nothing to do with this at all.

Then I had one more type of issue with the httpd, when I ran the httpd -V cmd:

AH00526: Syntax error on line 216 of /etc/httpd/conf.d/ssl.conf:
SuexecUserGroup configured, but suEXEC is disabled: Invalid owner or file mode for /usr/sbin/suexec

which had 510 permission with root:apache user:group pair. Changing it to 0750 solved this issue. I also dont know if it's realated - I guess this time that it must be, because a description I found about the suexec said that it's running the php-cgi. It didn't helped on the overall situation tho.

Then I checked the httpd modules, I did have this module in the /etc/httpd/modules/ folder: mod_proxy_fcgi.so only, which ofc doesn't mean that it's running the php with this, but I can assume without checking the file - I should confirm it from the config file tho.

There is a file in the conf.d folder: php.conf.rpmsave, where it says:

    # Proxy declaration
<Proxy "unix:/var/run/php-fpm/default.sock|fcgi://php-fpm">
        # we must declare a parameter in here (doesn't matter which) or it'll not register the proxy ahead of time
        ProxySet disablereuse=off

# Redirect to the proxy
<FilesMatch \.php$>
        SetHandler proxy:fcgi://php-fpm

I'm not sure if this matters here, because it might be only a saved config file for the previous package manager php version. Also if I say: sudo find / -name php.conf or sudo find / -name *hp.con*, then I get back only this one file, so it seems like the compiled version didn't generate a config file for the apache - maybe it doesn't have to at all, but maybe this is the problem here. Renaming it with mv to php.conf, changes actually the default response from the port 80 from the fancy Testing 123.. to 503 Service Unavailable. This is might be because last time when I compiled the php I excluded the php-fpm, so now I'm going to recompile it once again. Restarting the httpd and php-fpm services after it was done - didn't help on the situation.

From what I see, it's possible to have multiple versions of php script files on the system - which is kinda logical - and the cgi - fcgi, fpm and cli versions are also all different scripts.

Threading is only possible from the CLI version, so maybe if I would use the package version for the sites and then for the threading I would call the compiled CLI php version, then it might would do what I really want it for - as a plan B.

Also php command is not recognised after I installed the compiled versions with the make install cmd each time. Maybe this is something the installer should take care of - maybe not, after all I put the compiled binary folder into the $PATH variable and also added it to a .sh script in the profile.d folder

  • First you need to identify in your configuration, what module do you use to run PHP scripts: mod_proxy_fcgi, mod_php, mod_fcgid, etc. Look for a <FilesMatch> block for .php files and a SetHandler directive. The Apache2 error log /var/log/apache2/error.log might also help. Mar 9 '20 at 18:20
  • I just updated the description with the today's progress. Also thanks for the help, it really gives me ideas where to look for finding the issue. Mar 10 '20 at 16:56
  • A grep -C 2 SetHandler -R /etc/apache2 will search the configuration faster. The *.rpmsave file probably is not sourced by apache2.conf: the Include directives can confirm it. Mar 10 '20 at 17:43
  • I solved the issue. Using the hints you gave me I checked the config files - there was a for the php-fpm, the socket folder was missing, however this doesn't solved the case yet. Then I compared the modules of the "live" dev server - which I'm going to replace with this one, and I saw that the libphp7.so and zts version module is missing in the etc/httpd/modules/ From that I find out that I have to install the httpd-devel package and then recompile the php with this configuration flag: --with-apxs2=/usr/bin/apxs Mar 11 '20 at 12:36
  • I find out these by your help, so I would like to give the point to you. So if you create an anwser from the comments, I'll accept it as an answer, because the original question is "So what I would like to know is some kind of clue about how to figure this out, or some explanation about what files should be placed where and why?" Thanks again! Mar 11 '20 at 12:38

Do not replace any of the files provided by your distribution, as it will seriously break your system. The correct place for self-compiled versions is under /usr/local/.

For your CentOS 7 you could utilize e.g. these tutorials:

  • Thanks for the help, I checked the descriptions, and it seems logical to me, but I still couldn't find the issue. I also upgraded the q with the today's progress. Mar 10 '20 at 16:58
  • If you have mod_proxy_fcgi configured, you need to run php-fpm by yourself. In any case it is a good occasion to switch to it. Mar 10 '20 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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