Internal Server Error after PHP upgrade

D.O.A.

Well-known member
I have tried to upgrade to latest 5.3x stable PHP and gotten the same errors again, 500 internal errors when I use anything higher than 5.2.17. My host tells me xenforo is broken, I'm telling them it's the permissions for the domain or suphp user or something. As any .php file will work except xenforo files this makes it more confusing. The requirements file will run, and pass everything, .phpinfo.php no problems... but anything xenforo = 500 internal error.

the installer will run and fail at /install/index.php?install/step/2b

apache

[Sat Jul 23 22:37:13 2011] [error] [client 207.46.194.68] Premature end of scrip t headers: index.php
[Sat Jul 23 22:37:13 2011] [error] [client 207.46.194.68] Premature end of scrip t headers: index.php
[Sat Jul 23 22:37:23 2011] [error] [client 66.249.71.185] Premature end of scrip t headers: index.php
[Sat Jul 23 22:37:24 2011] [error] [client 66.249.71.185] Premature end of scrip t headers: index.php
[Sat Jul 23 22:37:34 2011] [error] [client 66.249.71.185] Premature end of scrip t headers: index.php
[Sat Jul 23 22:37:34 2011] [error] [client 66.249.71.185] Premature end of scrip t headers: index.php
suexec

[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 20:50:50]: uid: (507/*****) gid: (504/*****) cmd: php5
[2011-07-23 22:19:16]: uid: (507/*****) gid: (504/*****) cmd: whmredirect.cgi
suphp

[Sat Jul 23 22:42:10 2011] [info] Executing "/home/*****/public_html/forum/index.php" as UID 507, GID 504
[Sat Jul 23 22:42:10 2011] [info] Executing "/home/*****/public_html/forum/index.php" as UID 507, GID 504
[Sat Jul 23 22:42:10 2011] [info] Executing "/home/*****/public_html/forum/index.php" as UID 507, GID 504
[Sat Jul 23 22:42:10 2011] [info] Executing "/home/*****/public_html/index.php" as UID 507, GID 504
[Sat Jul 23 22:42:11 2011] [info] Executing "/home/*****/public_html/forum/index.php" as UID 507, GID 504
[Sat Jul 23 22:42:11 2011] [info] Executing "/home/*****/public_html/forum/index.php" as UID 507, GID 504
anyone have ideas why this keeps happening on PHP upgrade? (using easyapache) is suphp or exec responsible? my host insist xenforo is incompatible with higher versions of PHP

I'm on a semi-dedicated server with cpanel, WHM etc.
 

D.O.A.

Well-known member
something like that I thought they'd easily spot, I've also created a entire new account in WHM and found 500 errors there installing xenforo. Oddly enough wordpress and other scripts including VB have no trouble working on the same account in different folders, the forum will 500 die internally no matter where I upload the files.
 

D.O.A.

Well-known member
still no go. :unsure:
We checked the ownerships and permissions are all good. The UID/GID you provided are actually '*****' user's User and Group IDs. Please check below:
--
root@server [/home/*****/public_html/forum]# cat /etc/passwd | grep 507
*****:x:507:504::/home/*****:/bin/bash
root@server [/home/*****/public_html/forum]# cat /etc/group | grep 504
*****:x:504:*****
--
Also fastCGI is already disabled on the server and it should not be causing this problem.
Does your application have some specific requirement?
 

D.O.A.

Well-known member
I've compiled php 5.3.6/ suexec & suphp and tried working out the errors, by myself and with the data center techs managing my server. it's not happening. Strike that off your list if you ever upgrade via easyapache or command line. PHP 5.2.17 in the same configuration, same permissions and owners will run fine however.

I'm now using FastCGI PHP 5.3.6 with APC running in the background and xenforo runs fine without any internal errors or extra work on my part. Moral of the story is, suphp + latest php + xenforo = good luck with that.

Opcode caching is useless using suphp so I needed to move away from using it altogether, I'm sure it's a common mistake most whm/cpanel users would make anyway. You can install APC, xcache etc, but they wont do anything with non persistent PHP instances.
 

brendanc

Active member
I've compiled php 5.3.6/ suexec & suphp and tried working out the errors, by myself and with the data center techs managing my server. it's not happening. Strike that off your list if you ever upgrade via easyapache or command line. PHP 5.2.17 in the same configuration, same permissions and owners will run fine however.

I'm now using FastCGI PHP 5.3.6 with APC running in the background and xenforo runs fine without any internal errors or extra work on my part. Moral of the story is, suphp + latest php + xenforo = good luck with that.

Opcode caching is useless using suphp so I needed to move away from using it altogether, I'm sure it's a common mistake most whm/cpanel users would make anyway. You can install APC, xcache etc, but they wont do anything with non persistent PHP instances.
Do you have problems with uploading attachments? I can't get them to work with FastCGI. On 1.0 they fail silently (upload bar "hangs" at 100%) and on 1.1 it gives me an error but doesn't log an error anywhere, xenforo or system side. I'm using PHP 5.3.8.
 

D.O.A.

Well-known member
Do you have problems with uploading attachments? I can't get them to work with FastCGI. On 1.0 they fail silently (upload bar "hangs" at 100%) and on 1.1 it gives me an error but doesn't log an error anywhere, xenforo or system side. I'm using PHP 5.3.8.
There is something you need to add to httpd.conf for it to work, I'm at work now but in a few hours I will post my changes or Google fastcgi upload error httpd.conf fix.
 

D.O.A.

Well-known member
Do you have problems with uploading attachments? I can't get them to work with FastCGI. On 1.0 they fail silently (upload bar "hangs" at 100%) and on 1.1 it gives me an error but doesn't log an error anywhere, xenforo or system side. I'm using PHP 5.3.8.
without seeing your error logs you can either edit /etc/apache2/mods-available/fcgid.conf and make these changes
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
FcgidConnectTimeout 20
# to get around upload errors when uploading images increase the MaxRequestLen size to 15MB
MaxRequestLen 15728640
</IfModule>
but I do it in httpd.conf like below, probably the "easier" option of the two, depending on how php was compiled (easyapache/cpanel setups are a little different with paths and stuff) or locate fcgid.conf with putty and increase that setting. I'd try httpd.conf first and add the module settings below.
<IfModule mod_fcgid.c>
MaxRequestLen 111048576
IdleTimeout 3600
ProcessLifeTime 7200
MaxProcessCount 1000
DefaultMinClassProcessCount 3
DefaultMaxClassProcessCount 100
IPCConnectTimeout 8
IPCCommTimeout 360
BusyTimeout 300
</IfModule>
Remember to restart apache after editing, then test. hope this helps :)

after that, I also posted in here someplace how to get the PECL imagick extension working with this fastcgi/latest php, if you need it.
 

brendanc

Active member
I was able to add MaxRequestLen to my fcgid.conf file, and that fixed the problem. I also had to add upload_max_size to "globals" php parsed ini file, so that php would pick it up in the chrooted environment.

I have not been able to get PECL imagick working, though. My VPS runs CentOS, and I got ImageMagick and ImageMagick-devel installed, but PECL won't install imagick because /tmp is mounted with noexec. I think I need to talk to mediatemple about that.
 

brendanc

Active member
I was able to add MaxRequestLen to my fcgid.conf file, and that fixed the problem. I also had to add upload_max_size to "globals" php parsed ini file, so that php would pick it up in the chrooted environment.

I have not been able to get PECL imagick working, though. My VPS runs CentOS, and I got ImageMagick and ImageMagick-devel installed, but PECL won't install imagick because /tmp is mounted with noexec. I think I need to talk to mediatemple about that.
Agh, nevermind. I figured it out.

I had to do (as root):

Code:
mkdir ~/tmp
mount --bind ~/tmp /var/tmp
mount -o remount,exec /var/tmp
pecl install imagick
Then it worked fine. For anyone doing this, make sure you run mount first to find out how it was mounted prior to doing this. That way you can remount the directory to its previous state. In my case:

Code:
mount -o remount,noexec /var/tmp
umount ~/tmp
 

D.O.A.

Well-known member
What was the final cause of this DOA ?
I read the thread but still are not sure :)
Something weird was happening with the cpanel suPHP handler. I since switched to FPM/FastCGI handler on a nginx install and it's all good. suphp doesnt support opcode cache either so it's useful only up to a certain point.
 
Top