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.

phpsuexec x86_64 problems

Discussion in 'General Discussion' started by organica, Jan 11, 2006.

  1. organica

    organica Member

    Joined:
    Nov 10, 2005
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    I seem to be alone here with this issue of PHPSuExec not working correctly (thus remaining disabled) on a 64bit AMD server. Everything else I have enabled on the machine is running smooth (as far as a newbie is concerned).

    Once phpsuexec is enabled, I get intermittent 500 errors on my test site (.htacces is empty) and core dumps. It almost works :p !

    Has anybody found a fix? Or running into the same issues?

    Server Specs:

    WHM 10.8.0
    cPanel 10.8.1-R105
    RedHat Enterprise 3 x86_64 - WHM X v3.1.0

    Processor Information

    Processor #1 Vendor: AuthenticAMD
    Processor #1 Name: AMD Athlon(tm) 64 Processor 3200+
    Processor #1 speed: 1994.287 MHz
    Processor #1 cache size: 512 KB

    Memory Information

    Memory: 943388k/981952k available (1677k kernel code, 36000k reserved, 1577k data, 184k init)

    System Information

    Linux earth.organicaweb.com 2.4.21-37.EL #1 Wed Sep 7 13:49:00 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
     
  2. Coffeymate

    Coffeymate Active Member

    Joined:
    Jun 27, 2003
    Messages:
    30
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Atlanta
    I'd like to hear how this works out for you.
    We're looking at some new AMD 64 boxes and had hoped 64 bit would work smoothly now with everything.

    So I take it that if you turn off phpsuexec the problems go away and everything else is functioning properly, right?
     
  3. organica

    organica Member

    Joined:
    Nov 10, 2005
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Well, yes and no. We had to change gcclib from i686 to i386 in order to update Perl and Mailscanner. Everything else is running smooth as can be.

    I'm just worried about the vulnerabilities on the server without using the phpsuexec modules. It's also a pain to set permissions for my php site customers.

    Nobody seems to know of a fix. Has anybody tried?
     
  4. neverpanic

    neverpanic Registered

    Joined:
    Dec 3, 2005
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Just make sure that these files are owned by the user that executes them.
    I think phpSuExec throws an 500 error on chmod 777 files owned by another user.
    Just exec chown -R [cpanel username] /home/[cpanel username] in shell and see if it works.
     
  5. organica

    organica Member

    Joined:
    Nov 10, 2005
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    The /home/* folders are chown correctly; however, from what I gather sud-directories should not all be owned by the cpanel user. Some must be owned by mail and nobody. But all other directories and files are chown[ed] by the cpanel user.

    Before I had Chirpy try to get PHPsuexec going for me (which he could not figure what is wrong either by the way), I executed #/scripts/chownpublichtmls. Chirpy and ThePlanet.com's tech support both said I should wait until Cpanel comes out with something more compatible with x86_64 or a fix.

    Any other ideas?

    EDIT* public_html directory is chown user:nobody. Could this be the culprit? I would think not becuase in this case I would get all 500 errors or none at all.
     
    #5 organica, Jan 16, 2006
    Last edited: Jan 16, 2006
  6. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    I'll just add:

    You're right in that you should use /scripts/chownpublichtmls to set the correct permissions on the /home/* directories. You should definitely not chown user:user /home/user/public_html, it should indeed be user:nobody.

    The problem that we saw when compiling phpsuexec on x86_64 was that php would randomly core-dump. It appears to work for ~80% of page loads then would suddenly core-dump and then would work again on exactly the same script. So it's not a permissions/ownership issue, it's definitely a module compilation problem in that environment. A real pain. It does seem that x86_64 isn't really ready for production servers, especially if you're running cPanel on them.
     
  7. hekri

    hekri Well-Known Member

    Joined:
    Oct 14, 2003
    Messages:
    149
    Likes Received:
    2
    Trophy Points:
    18
    On redhat enterprise x86_64 fresh instalation work 30% cpanel

    Dont install cPanel on redhat enterprise x86_64 you will have only problems, i fixed problems to 80% cpanel work but no one know on the forum how to fix last 20% i reinstall system to i686
     
  8. organica

    organica Member

    Joined:
    Nov 10, 2005
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    PHPSuexec is running on my machine now without any 500 errors.

    It's silly how I got it running, but logical. I ran #/scripts/chownpublichtmls, then enabled GZip in cpanel's Apache Update (no relation probably), compiled, restarted, then enabled PHPsuexec in Apache Update, compiled, and restarted. Voila. Websites work (at least from a web browser's point of view).

    But, I now get this error from the CPU:

    Code:
    Jan 17 09:27:03 earth kernel: APIC error on CPU0: 40(40)
    [Tue Jan 17 09:01:44 2006] [error] [client 68.225.121.112] Premature end of script headers: /home/visitwat/public_html/index.php
    It seems that I only get this error from ONE account. After some research on this APIC error, people say to flag -noapic at boot time. Not going to do it unless I know it's safe or necessary.

    Chirpy, is this the core dump message you were referring to? If it is not, what could be done about fixing this issue?

    BTW- No offense to Chirpy or ThePlanet.com team from my previous post:
    They have been doing an absolute kick *ss job working with my server. Kudos to asmithjr on this forum as well! I would be out of business by now if not for them! :)
     
    #8 organica, Jan 17, 2006
    Last edited: Jan 17, 2006
Loading...

Share This Page