Updated: FCGID stopped working

Hi all,

I’m facing the following issue:
I updated the packages yesterday that virtualmin proposed. Sadly, I did it blindly.

Since then (though I noticed it only this evening, 24 hours later) the websites only show the raw php code.
PHP is not executing.

I changed the php exec mode from one server to mod_php and that site works.

From this I’m assuming the problem exists with the FCGID.

Running: centos 6.4
Kernel and CPU Linux 2.6.32-358.14.1.el6.x86_64 on x86_64
Virtualmin 4.0.1

LOGS: The only thing the logs tell me is that php is not executing anything:

[Mon Aug 05 20:30:09 2013] [error] [client xxx.xxx.xxx.xxx] PHP Notice: Use of undefined constant DIRECTORY_PATH_INC - assumed ‘DIRECTORY_PATH_INC’ in /home/xxx/public_html/modules/index.php on line 14
[Mon Aug 05 20:30:09 2013] [error] [client xxx.xxx.xxx.xxx] PHP Warning: require_once(DIRECTORY_PATH_INCdesign.inc.php): failed to open stream: No such file or directory in /home/xxx/public_html/modules/index.php on line 14
[Mon Aug 05 20:30:09 2013] [error] [client xxx.xxx.xxx.xxx] PHP Fatal error: require_once(): Failed opening required ‘DIRECTORY_PATH_INCdesign.inc.php’ (include_path=’.:/usr/share/pear:/usr/share/php’) in /home/xxx/public_html/modules/index.php on line 14

I restarted the server, restarted quite a lot of things.

Can anybody help me?
FCGI really needs to run fast. The flagship website for that server does not work properly under mod_php…

Thanks

EDIT: I have read it might be a wrong path of PHP

I did the following:

[root@server xx]# pear version PEAR Version: 1.9.4 PHP Version: 5.4.17 Zend Engine Version: 2.4.0 Running on: Linux server.xx.net 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 [root@server xx]# php --ini Configuration File (php.ini) Path: /etc Loaded Configuration File: /etc/php.ini Scan for additional .ini files in: /etc/php.d Additional .ini files parsed: /etc/php.d/apc.ini, /etc/php.d/curl.ini, /etc/php.d/dom.ini, /etc/php.d/fileinfo.ini, /etc/php.d/gd.ini, /etc/php.d/imap.ini, /etc/php.d/json.ini, /etc/php.d/mbstring.ini, /etc/php.d/mcrypt.ini, /etc/php.d/memcache.ini, /etc/php.d/mysql.ini, /etc/php.d/mysqli.ini, /etc/php.d/odbc.ini, /etc/php.d/pdo.ini, /etc/php.d/pdo_mysql.ini, /etc/php.d/pdo_odbc.ini, /etc/php.d/pdo_pgsql.ini, /etc/php.d/pdo_sqlite.ini, /etc/php.d/pgsql.ini, /etc/php.d/phar.ini, /etc/php.d/snmp.ini, /etc/php.d/sqlite3.ini, /etc/php.d/wddx.ini, /etc/php.d/xmlreader.ini, /etc/php.d/xmlrpc.ini, /etc/php.d/xmlwriter.ini, /etc/php.d/xsl.ini, /etc/php.d/zendguard.ini, /etc/php.d/zip.ini

[root@server xx]# php -c /etc/php.ini -r ‘echo get_include_path()."\n";’
.:/usr/share/pear:/usr/share/php
[root@server xx]# pear config-get php_dir
/usr/share/pear

[root@server xx]# php -v
PHP 5.4.17 (cli) (built: Aug 1 2013 11:12:15)
Copyright © 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright © 1998-2013 Zend Technologies
with Zend Guard Loader v3.3, Copyright © 1998-2013, by Zend Technologies

Might it be zenguard or apc acting up?

Digging digging digging …

I’ve found this interesting error:

[04-Aug-2013 22:25:01 UTC] PHP Warning: PHP Startup: uploadprogress: Unable to initialize module
Module compiled with module API=20090626
PHP compiled with module API=20100525
These options need to match
in Unknown on line 0
[04-Aug-2013 22:25:01 UTC] PHP Warning: PHP Startup: ffmpeg: Unable to initialize module
Module compiled with module API=20090626
PHP compiled with module API=20100525
These options need to match
in Unknown on line 0

Edit

reinstalling uploadprogress terminates the error.
reinstalling ffmpeg does not remove the ffmpeg error

Solved:

For some reason the upgrade to the new PHP 5.4.17 changes the option short_open_tags to Off in all php.ini files.

Solution: change short_open_tags to On in all php.ini files.

Moral: as usual it is a stupid setting that has been overlooked.

Edit:
I cheered too soon.
It appears that the above is true when setting the php exec mode to mod-php.
But as soon as I set it to fcgid, I get the same problem again.

Ah well, the site is running now. It can hold for now on this mod-php until I have time to install a new server and do things differently.

Any more news on this? It seems to be a wider spread issue than this one thread? I encountered similar problems with my Centos 5.9 / upgrade to PHP 5.4.13

It started a few weeks ago after an auto update and all my sites went down. After much searching I managed to get a fix of sorts by changing all the sites individually to mod_php mode and run them with apache user and group instead of the FCGI option.

A few weeks on I have tried to return some of the sites to FCGI version but it causes them to crash and only display a php file/error in the browser window.

I cannot now revert them to the mod_php mode either.

The sites that I did not change are still up and running but three sites I “tested” with are still down. This seems to imply it is a virtual/domain related issue?

I have tried various options suggested on various posts on here and around the web to comment out the Sethandler lines and various solutions like that. But none have worked. (including restarts of server etc)

I am three days in to this problem and not a linux guru by any stretch more of a casual administrator so any step by step suggestions would be much appreciated! I am close to self harm on this one and vowing to get out of IT related work and back to fishing for a job.

Other aspects that may be important…
The server is reporting only php 5.4.13 is installed but there is an option to configure an older php 5 in the menu and both links bring up a configuration page. However, it is not possible to set any domain to a different type of php as it insists on using the php_mod option under website options in webmin.

Webmin itself is showing as wanting to update itself but when I try using the install updates feature it returns an error and fails which I have pasted in below in case it helps with any diagnostics.

Do I have the “right” php version from the atomic repository is a possible question that I may have got wrong when doing an initial upgrade / trying to sort it out.

All mods suggested I have subsequently changed back to how it was before where possible so that I don’t move to many goal posts whilst trying to diagnose the problem.

The error logs do not give any particular clues about what is going wrong that I can see.

When I commented out sethandler at one point I could get to see a kickstart.php file running OK on one domain but the actual domain then came up with a couldn’t connect to database error so the site still would not display and I changed it back in order to not “break” the other websites on this production server.

Two of the sites that have gone down were running fine prior to seeing if i could change them back in website options from mod_php to FCGI.

Although it says it is changing them to FCGI when you go back to website options it is in fact still on mod_php mode.

Any help much appreciated!

I am now back up and running. It required an involved downgrade back to php 5.3.9 though.

As far as I can tell upgrading to php 5.4 has some many issues they are not particularly solvable with one quick fix or with any set handlers being commented out etc.

I used the graphical interface via Gnome to remove all the php54 packages and then reinstalled php53. don’t forget to restart Apache afterwards too :slight_smile:

I had used the Atomic repo for the php54 and that is where all the problems started. Not saying anything is wrong with the repro but sticking to Virtualmin / Centos recommendations is clearly the (obvious) thing to do.

upgrading from Centos 5.9 to 6.X is not that automatic to also get to higher php versions so I will build a new server from scratch and port the data and websites over.

I can now change modes again between FCGID and apache etc and everything is working again.

I also learnt a lesson about upgrading production servers being over confident in my abilities and now have a cloned virtual server to “experiment on” first!

Three and a half days of stress and no sleep and only one client moderately annoyed out of many was a relatively good outcome. That’s it I am off fishing now!