The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

suphp issues ?

Discussion in 'General Discussion' started by Tech Entrance, Nov 13, 2007.

  1. Tech Entrance

    Tech Entrance Member

    Joined:
    Jun 2, 2007
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    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.
     
  2. marsupillami

    marsupillami Member

    Joined:
    Jan 20, 2006
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    DataCenter Provider
  3. jerrybell

    jerrybell Well-Known Member

    Joined:
    Nov 27, 2006
    Messages:
    90
    Likes Received:
    0
    Trophy Points:
    6
    Those are the symptoms of improper permissions. Have the permissions on the public_html's and contents changed? Are they correct?
     
  4. Tech Entrance

    Tech Entrance Member

    Joined:
    Jun 2, 2007
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    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



    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"
     
  5. darren.nolan

    darren.nolan Well-Known Member

    Joined:
    Oct 4, 2007
    Messages:
    259
    Likes Received:
    0
    Trophy Points:
    16
    suexec_log & suphp_log are located in /usr/local/apache/logs for my setup.

    Try
    locate suphp_log
     
    #5 darren.nolan, Nov 14, 2007
    Last edited: Nov 14, 2007
  6. Tech Entrance

    Tech Entrance Member

    Joined:
    Jun 2, 2007
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    cool found it and it was 2GB just as the guy from suphp told me

    now just delete it and enable suphp again ?
     
  7. darren.nolan

    darren.nolan Well-Known Member

    Joined:
    Oct 4, 2007
    Messages:
    259
    Likes Received:
    0
    Trophy Points:
    16
    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.
     
  8. Tech Entrance

    Tech Entrance Member

    Joined:
    Jun 2, 2007
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    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
     
  9. darren.nolan

    darren.nolan Well-Known Member

    Joined:
    Oct 4, 2007
    Messages:
    259
    Likes Received:
    0
    Trophy Points:
    16
    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).
     
  10. marsupillami

    marsupillami Member

    Joined:
    Jan 20, 2006
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    DataCenter Provider
    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
     
  11. Tech Entrance

    Tech Entrance Member

    Joined:
    Jun 2, 2007
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    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.
     
  12. freedman

    freedman Well-Known Member

    Joined:
    Feb 13, 2005
    Messages:
    312
    Likes Received:
    1
    Trophy Points:
    18
    make sure this log is being rotated. check /etc/logrotate.d/httpd
    mine looks like this:

    Code:
    /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
    }
    
     
  13. darren.nolan

    darren.nolan Well-Known Member

    Joined:
    Oct 4, 2007
    Messages:
    259
    Likes Received:
    0
    Trophy Points:
    16
    What error if any are you getting this time?
     
  14. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    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.
     
  15. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    The suphp_log will be rotated automatically in the next release.
     
  16. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    my log has been rotating automatically (at least I never told it to), but it's still a lot of stuff in there :)
     
  17. freedman

    freedman Well-Known Member

    Joined:
    Feb 13, 2005
    Messages:
    312
    Likes Received:
    1
    Trophy Points:
    18
    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
    Code:
    ; 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
     
  18. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    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.
     
Loading...

Share This Page