suphp issues ?

[Tech Entrance]

I use "suphp" on 3 servers I own with apache 2.2.6 and suddenly yesterday (15 hours ago) one of the servers show "Internal server error" on all sites.

Tried rebuilding apache and php 4 times with no fix until I came to try handling php with cgi instead. (I always like to track who is using apache processes)

well. getting to this fix was after 10 hours of all sites not working on the server.


I came to the solution
that it is suphp causing the problem so I set php to be handled by cgi
instead of supsp in

Main >> Service Configuration >> Configure PHP and SuExec

OLD config


Default PHP Version (.php files) 5
PHP 5 Handler suphp
PHP 4 Handler none
Suexec on

NEW config

Default PHP Version (.php files) 5
PHP 5 Handler cgi
PHP 4 Handler none
Suexec on


Those settings got my server back online but the problem is that bandwidth is not being counted since apache won't process cgi scripts bandwidth usage.

really want to get suphp back running asap

note that I use release builds since ever and latest release build is 2 weeks old so might be only some packages updated when cpanel cron ran yesterday without the version being changed ?

hope to get a clue on this.

 

[marsupillami]

Same Problem here ... http://forums.cpanel.net/showthread.php?t=72953&highlight=cpanel+suphp

 

[jerrybell]

Those are the symptoms of improper permissions. Have the permissions on the public_html's and contents changed? Are they correct?

 

[Tech Entrance]

Interesting, what are the file permissions on the PHP files that have stopped working?

Also, is this a Linux or FreeBSD server as I know FreeBSD + suPHP had a weird bug where the ownership (user:user) had to be set correctly instead of user:nobody which used to work with phpSUEXEC.

That bug has since been fixed... well it's not really a bug, it's just cPanel didn't have suPHP setup correctly for FreeBSD when it was pushed out in EA3.

file permissions were 644 and I tried 755 and even 777 didn't work

all php files were not working

Got that reply from suphp.org

The problems with the suPHP website were caused by a problem with PHP,
not suPHP: PHP did not work because I upgraded a library that PHP
depends on and the new version's ABI was incompatible, so I had to
recompile PHP to make it work again.

If suPHP stopped working suddenly without any change on the system, you
should check the size of the suPHP log file. If the log file has reached
the 4 GB (or 2 GB?) limit, suPHP will not be able to open the log file
and fail because it is usually not compiled with large file support.

Now where should I look for the suphp log file to delete it ?

went to /var/log/ didn't find any suphp related file/folder

I have another server with suphp enabled till now and working fine and also there is no suphp related files in /var/log/

This is the path that I got after searching in google for "suphp logs"

 

[darren.nolan]

suexec_log & suphp_log are located in /usr/local/apache/logs for my setup.

Try
locate suphp_log

 

[Tech Entrance]

suexec_log & suphp_log are located in /usr/local/apache/logs for my setup.

Try
locate suphp_log

cool found it and it was 2GB just as the guy from suphp told me

now just delete it and enable suphp again ?

 

[darren.nolan]

yeah - lol. It reached 2gb? Crazy! Remember this for next time and maybe setup a log rotation or the like.

Just ensure that whatever file permissions and owner details are and make the same when you touch a new file. (Or just dump out the current file).

Should be root:nobody and chmod 0600 on my setup.

 

[Tech Entrance]

I just renamed the file and enables suphp again and it works fine - it created a new log file (1.3MB now)

ofcourse I will remember this next time - it was a nightmare

Thanks a lot for your help - I owe that guy from suphp.org some sweets as well :D

 

[darren.nolan]

I owe that guy from suphp.org some sweets as well :D

Wine normally works better. It's good that it made the file itself, but if it's at 2mb in less than an hour it's not going to take long before it's full again.

Checkout a log rotation script that you can do up, and delete logs older than say 30 days (it's nice to have logs for random incidents).

 

[marsupillami]

Yes, that was the problem. suPHP is outputting too much information. Each time a user accesses a website, it outputs a line:

[Wed Nov 14 16:46:08 2007] [info] Executing "/home/wowtuga/public_html/shoutbox.php" as UID 32068, GID 32069
[Wed Nov 14 16:46:08 2007] [info] Executing "/home/techtuga/public_html/top/button.php" as UID 32238, GID 32240
[Wed Nov 14 16:46:08 2007] [info] Executing "/home/wowtuga/public_html/shoutbox.php" as UID 32068, GID 32069

 

[Tech Entrance]

Actually this error 500 has decided to show up again today (3 hours till now) and even if I delete suphp logs it still doesn't work.

I tried to rebuild apache several times but it's not working and it happened on both the server at the same time.

 

[freedman]

cool found it and it was 2GB just as the guy from suphp told me

now just delete it and enable suphp again ?

make sure this log is being rotated. check /etc/logrotate.d/httpd
mine looks like this:

/usr/local/apache/logs/*log {
    compress
    delaycompress
    rotate 5
    weekly
    missingok
    notifempty
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /usr/local/apache/logs/httpd.pid 2>/dev/null` 2> /dev/null || true
    endscript
}

 

[darren.nolan]

Actually this error 500 has decided to show up again today (3 hours till now) and even if I delete suphp logs it still doesn't work.

I tried to rebuild apache several times but it's not working and it happened on both the server at the same time.

What error if any are you getting this time?

 

[verdon]

Yes, that was the problem. suPHP is outputting too much information. Each time a user accesses a website, it outputs a line:

[Wed Nov 14 16:46:08 2007] [info] Executing "/home/wowtuga/public_html/shoutbox.php" as UID 32068, GID 32069
[Wed Nov 14 16:46:08 2007] [info] Executing "/home/techtuga/public_html/top/button.php" as UID 32238, GID 32240
[Wed Nov 14 16:46:08 2007] [info] Executing "/home/wowtuga/public_html/shoutbox.php" as UID 32068, GID 32069

Looks like you can control the logging detail/level in the suphp.conf file. For me, that is at /opt/suphp/etc/suphp.conf

The default (for me) is loglevel=info I did a little googling and it looks like it can also be warn or error and maybe other options, but I am unsure.

 

[cPanelNick]

The suphp_log will be rotated automatically in the next release.

 

[verdon]

my log has been rotating automatically (at least I never told it to), but it's still a lot of stuff in there

 

[freedman]

my log has been rotating automatically (at least I never told it to), but it's still a lot of stuff in there

I agree.

Nick.. would it be possible to add some conf tweaks to EA3?
for example, if suphp is selected, you get another option for "log level" and can select from the 4 options.
Same for any other .conf based configuration.
Especially given, in this case, EA3 will feel free to just willy nilly overwrite the conf file anytime it feels like, it'd be nice if it took some responsibility for restoring user desires as well.

NOTE: This assumption is based on the comments within the suphp.conf

; EasyApache 3 checks the following value to determine wether or not
; your suphp.conf is up to date.  Removing it will cause this file
; to be replaced the next time EasyApache is run
;
; cPanel suphp.conf version -- 43

 

[jdlightsey]

EA3 is actually using those marker comments to do editing of the suphp.conf file where possible. For instance, version 44 added the [phprc_paths] section for locking down the php.ini files and the upgrade from version 43 was done without resetting suphp.conf.

I'd imagine at this point the only reason we'd have to wipe suphp.conf instead of upgrading it in place would be if the next version of mod_suphp uses an entirely incompatible configuration syntax. The odds of that are fairly low.

If you'd like to see an interface for managing suphp.conf (or the configuration files of other new software introduced with EA3) it would be better to have it in the WebHostManager. I'd hate to think of users recompiling Apache and PHP just to change simple values in suphp.conf.