Clean new CentOS install : no Php working

I tried 4 times

  • install clean new CentOS 7, run virtualmin install
  • install clean new CentOS 6, run virtualmin install
  • install clean new CentOS 7, did a yum update, run virtualmin install
  • install clean new CentOS 7, run virtualmin install

PHP not working. (sends <? print "hello" ?>) to the world…
I tried for a week now a lot of things found on this forum and others, hunted handlers to comment it in or out, went to
server configuration => website options => and tried CGI, wraper, FCGI, FPM, scripts as domain owner yes or no… and all
went to serverconfiguration=> changes 5 to 7, 7 to 5 and again and again

Tell me, as of today feb 4th… what is wrong with latest Cent OS (CentOS Linux 7.7.1908), and the php installation with webmin. I looked several error records without finding anything

Nothing wrong with your OS. In your command line, type in “php -i” to check if PHP was indeed installed.


Tell me, as of today feb 4th… what is wrong with latest Cent OS (CentOS Linux 7.7.1908), and the php installation with webmin. I looked several error records without finding anything

If you installed Virtualmin manually there are hundreds of small manual steps that has to be taken to make things work. We do not recommend doing it.

On contrariety, automatic installation is taken only about 5-10 minutes, will provide you with working out of the box system.

Just download and run the installer script.

Note: Remember, it was to be run (installer script) on clean system, without any packages being installed or altered, to work as expected.

Hi I think it’s clear, I did 4 times exactly that, clean system and automatic installation.

Yes PHP is installed,

php -v

PHP 5.4.16 (cli) (built: Nov 1 2019 16:04:20)
Copyright © 1997-2013 The PHP Group

and php -v tells a zillion things and can’t see an error

I had a similar problem with a fresh install on a new CentOS 7 server. Check my thread where I explain the problem and how I worked it out in more detail, it may be the same issue you’re having.

I’ve just mentioned this in another thread. php seems to be improperly executing on clean installs of both Ubuntu 16.04 and Debian 10. Instead of execution, php is downloading file to browser.

Seems there is an issue with either the default .conf or default wrapper.
Appears to have started yesterday or the day before from what I can tell

Hi, thanks for this help
trying. but first, no such files in /etc/httpd/conf.modules.d
there’s one called 10-php.conf containing

<IfModule prefork.c>
LoadModule php5_module modules/

i installed PHP 5.5 and 7.3.
runned the recheck config :

The following PHP versions are available : 5.4.16 (/bin/php-cgi), 5.5.21 (/opt/rh/php55/root/usr/bin/php-cgi), 7.2.24 (/opt/rh/rh-php72/root/usr/bin/php-cgi), 5.4 (mod_php)
The following PHP-FPM versions are available on this system : 5.4.16 (php-fpm) 5.5.21 (php55-php-fpm) 7.2.24 (rh-php72-php-fpm)
PHP versions have changed to 5, 5.4, 5.5, 7.2 since last check. Regenerating any missing php.ini files.

Well, it did add back the commented out
php_admin_value engine Off

it rewrote in httpd.conf

AddType application/x-httpd-php .php
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
AddHandler fcgid-script .php5.5
AddHandler fcgid-script .php7.2
FCGIWrapper /home/exces/fcgi-bin/php5.5.fcgi .php
FCGIWrapper /home/exces/fcgi-bin/php5.fcgi .php5
FCGIWrapper /home/exces/fcgi-bin/php5.5.fcgi .php5.5
FCGIWrapper /home/exces/fcgi-bin/php7.2.fcgi .php7.2

RemoveHandler .php
RemoveHandler .php5
RemoveHandler .php5.5
RemoveHandler .php7.2
php_admin_value engine Off

i tried many stuffs

So this would be a general problem being also on Ubunto and Debian ?
My first attemps on a clean install was on jan 29th. If this can help.

Yes, I also just downgraded this server to Debian 9, created a server template using php7.2, created virtual server and installed software.

It appears, Virtualmin keeps defaulting to php7.4, even though I’ve also set the default version to 7.2…also when checking version using php -v I’m still showing 7.2

Find and disable all mod_php module loads you can find in the configs, my issue was that Virtualmin was disabling php-fcgi in each virtualhost because it thought I was going to be using mod_php (because it was installed). That was preventing PHP from being processed.

This would happen whenever I re-ran the config checker as long as the mod_php was being loaded. I explained it with config file examples in my post. Hopefully it’s the same root cause as your issue…

Hi, just letting you know…
I reinstalled a clean centos release and merely did just that : installed, httpd, very few stuffs such as phpMyAdmin, and MySQL 2 php releases (5.4, 7.2) like does the virtualmin installation script, and WEBMIN only, not virtualmin.
Php -v is ok and says 5.4.45
But PHP is not working on the default virtual host. I even changed the default /var/www/html to /home/centos/www and wrote the conf file from scratch… chmod directory and files to various levels… No success.
So the issue must be somewhere else from a very recent update (httpd 2.4.6 Aug 8 2019 11:41:18 ? ) doing yum. Strange is that PhpMyAdmin runs, and it seems to me that it’s running the php engine (right ?).
I looked at all conf files and I really can’t see or understand.

First of all, I would remove PHP 5.5 completely. It’s unsupported - the last branch, 5.6, was last updated over a year ago.

Ideally you should be running at least PHP 7.2 unless your code desperately requires an older version (and then, you need to seriously consider fixing your scripts).

When I did my clean install and updated from yum, it tried to load the mod_php module which caused all these problems. If you read my post, you’ll see this. :slight_smile:

Did you install phpMyAdmin (I’ll call it PMA from now) manually, or via one-click? I installed PMA onto a virtualhost manually so I had the same PHP not-parsing problem as on my other vhosts. If you’ve used the one-click installer, I wonder if it’s done something differently which has preserved PHP parsing…

I would have another look at all the virtualhost definitions.

In one of my site’s public_html <Directory> section, I have (including other things)

AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
AddType application/x-httpd-php .php
AddHandler fcgid-script .php
AddHandler fcgid-script .php7.3
FCGIWrapper /home/username/fcgi-bin/php7.3.fcgi .php
FCGIWrapper /home/username/fcgi-bin/php7.3.fcgi .php7.3

in 15-php73-php.conf I have my slightly modified config which disables mod_php loading:

# Cannot load both php5 and php7 modules
<IfModule !mod_php5.c>
  <IfModule prefork.c>
    #LoadModule php7_module modules/

Note I have #commented the LoadModule line

If you are missing all the FCGI-related lines in your site’s virtualhost definitions, as I understand it, Virtualmin has removed them because it thinks PHP is being loaded using mod_php. However, mod_php doesn’t work properly (at least, I couldn’t get it to work).

Manually modifying the virtualhost files was useless until I disabled the mod_php LoadModule completely, because virtualmin just re-wrote them and removed the lines. Disabling mod_php wasn’t very obvious at first.

If your Apache is loading it is causing this problem because it seems FCGI cannot coexist with mod_php very well on a Virtualmin install. It is possible, but honestly I could not make it work (and it seemed stupid to change from Virtualmin’s default, because it would make support harder).

To disable mod_php, just comment out the LoadModule line in the .conf file, then re-add the AddHandler and FCGIWrapper lines to your vhost (a bit repetitive, sorry) and your sites should start processing PHP again after you restart Apache.

Perhaps checking the configuration files would do this automatically, I haven’t tried… (from a command line, virtualmin check-config). Maybe just do the Apache configs:
virtualmin validate-domains --all-domains --feature web
(or you can do individual domains by altering the parameters, see

Remember to modify each site’s virtualhost for both port 80 and port 443 if you do it manually.

After commenting out the LoadModule line, I’ve not had any problems with yum updates to the latest security patches for PHP 7.3 - I just update modules, and everything works fine.

Right now, I’ll try a new clean install, and do step by step what you say. As I wrote, it’s such a minimal installation that I didn’t even bother 443 hosts or letsencrypt. Nonetheless, If I run the Webmin installation script it will install both 5.6 and 7.2 (or 7.3).
Anyway, yes, I need php 5 (possibly, just 5.3.3) that works fine, fast, and is relyable. I’m not of those who look for updates… My fine tuned, extremely safe, old server never falled under attacks wich happen every single day, every single hour.
In fact on this one site that runs under php5.3.3, I’m slowly updating Mysql lines to Mysqli. And I regret that.
MySQLI is slower and as many stated, I lost 5% to 20% query time. On some pages, it rised from 90ms to 170ms. The database is huge and has 20 years of archives. The site was first launched at christmas 1998 :slight_smile: and is one of the most visited site of the French Riviera. Some queries where very carefully writen at the time of MySQL 3.23 when subqueries for the never released 3.24 were an unkeepen promess :slight_smile: There are thousands of line of coding. each one query must be tested carefully (like undocumented mysql-fetch_row ($query, 0) doesn’t behave at all all like mysqli_fetch_row that does not take “,0”)The main concern isn’t php but MySQL and a strange behavior of PHP 5.6 with latin-ci charset from php 5.3. So my intend was about slowly through, let’s say, the next 10 years to “jump” to php 7. No hurry, really, dealing with google rich content, new css stuffs and all, should remain my priority. Just can’t beleive that it became so complicated to set a new server. I thought it was going to be a couple day work !
I’ll make another trial tuesday and write down step by step whats happening.

What about pointclick_digital_l troubles when he tried 4 days ago on Ubuntu 16.04 and Debian 10 ?

Whoah, that sounds like one huge dependency headache… :rofl: 20 years of archives! Impressive.

I’m glad to hear you have it well secured. Sounds like it’s an impressive big site, and you’ve kept the site going since 1998?! If it’s public, please send me the URL later, I’d like to check it out when it’s working :slight_smile:

I’m running MariaDB, I don’t host sites as big as yours but I’m interested to know if you compared the performance of Maria, My and Postgre. I know mysqli vs mysql is almost the same but mysqli supports more new features, but I don’t personally notice a performance hit on my small sizes.

On my older servers, I’ve kept MySQL and PHP locked at earlier versions, for the same reason as you, and it became a dependency nightmare with older software running on it for one client. Good luck, let us know how you get on…

I’m sure Joe or Ilia might have some good advice in this situation as well.

I did the clean install. It seems to me that there’s a very wrong doing by the “yum” install with PHP. And so must it be with the virtualmin all-in-one script.
For sure, the PHP-FPM. conf files were missing in /etc/httpd/conf.d/ directory.
Once again, php didn’t work at all on the first shot. I tries to comment out some, then all, then aal but one, read the whole night many tutorials, nothing to do in fact.
I’ll try another install and get to understand the PHP FPM stuf to make it as light as possible.

Would you like me to send you the various httpd conf files ?

Hello. Here I’m back again. Thanks for the lot of answer :roll_eyes:
I spent a lot of time this month testing several VPS and real servers for performance, using another pannel that works smoothly (but with fewer options).

So I gave a try to Virtualmin 10 days ago. And an another try yesterday and today.
The install script is new since the begining of this post. Version is 6.1.1. It says it’s ok on centos 8 in red. It did work on an AMD Opteron centos 7 server.

PHP works on some conditions .

  1. unlike any other install script, the install flag –
    short tags are disabled (the install script is missing –
    and/or the ini file should have short_open_tag = On. (Not the place here to argue about PHP decision, but “<?” came first and is the standart).
    So the usual trial <? echo "Hello world"; ?> won’t work. (I found it out searching hard and wondering why PhpMyAdmin was working).

  2. PHP FPM server is not enabled (does’nt restart at reboot). So if it would work at time of install… But then, after a reboot, well, you get a 503 “service una…”. It took me time to get that. Meanwhile, of course many stuffs wont work,; such as claming lets encrypt certificate ! (one new issue I have right now, even if i got rid of the 503 error)
    The service is called " rh-php72-php-fpm.service".
    On webmin, checking at this : image

So anyway, once you know…

  • systemctl start rh-php72-php-fpm.service
  • systemctl enable rh-php72-php-fpm.service


New server, new install…
If in server templates, PHP Options,

Default PHP exection mode : PHP FPM

if default PHP version is set to Highest available
php 5 FPM is choosen instead of PHP 7.2
if "PHP 7.2.24 is choosen, PHP 7 FPM will be started
but not enable (down at reboot)

if virtual server created with PHP 5 FPM, PHP-FPM server (php 5) is started and works
if changing PHP version, rh-php72-php-fpm.service fails to start, PHP-FPM (the v5) keeps running) (I guess because set on the same listening port).
must stop it and then start rh-php72-php-fpm.service

In anycase, if not manualy enabled in shell, it wont restart.

other disturbing behavior,
Editing the PHP options, ends up in a starge file named “/etc/opt/rh/rh-php72/php-fpm.d/15867900864270.conf” begining with a [15867900864270]
user =
And has no effect until complete server restart.

Would be nice if at time of Virtualmin installation, the script would ask about time zone preference. Because as it is asked to use a fresh copy of the system, my server was set to UTC. So it was then hardcoded into the default php.ini file.

Hope this helps others and hope this bug will be corrected

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.