Skip to main content

Apache failing after EasyApache update

Comments

35 comments

  • vacancy
    I see the same error on my 2 servers. I went back to easyapache 3 to solve the problem. yum -y upgrade I did not solve the problem.
    0
  • Reado
    Run "yum -y update". I had the same problem, ran yum again and it resolved the problem for me. Looks like Apache was compiled yesterday and then again today.
    0
  • John Galvin
    After last nights Easy Apache update, httpd is failing with the error: Starting httpd: /usr/sbin/httpd: symbol lookup error: /usr/sbin/httpd: undefined symbol: apr_allocator_align Originally I had an error that libapr-1.so.0 couldn't be found in /lib64/libapr-1.so.0, so I created a symlink from there to /opt/cpanel/ea-apr15/lib64 where it's located, but now I can't past the above error. Anyone encountered this or know how to resolve it?
    0
  • tim_proc
    Just a quick note to say we ran into the same issue. Ended up re-provisioning with Easy Apache 4 using the same profile.... as per the first message we seen raw PHP code being rendered. This was solved by resetting the PHP handlers again (for all versions) to suPHP in our case. A bit more long-winded than @Raedo's solution but worked for us. We're a bit pissed that we can't control this auto-update process though tbh.
    0
  • OttoM
    Hello, The httpd has been down on my server since 1.30am. I can ssh and run the command to start it. service httpd start But getting these error messages: Apr 04 12:25:16 vps.online-example.com systemd[1]: Starting Apache web server managed by cPanel EasyApache... Apr 04 12:25:16 vps.online-example.com restartsrv_httpd[3627]: /usr/sbin/httpd: symbol lookup error: /usr/sbin/httpd: undefined symbol: apr_stat_fd Apr 04 12:25:16 vps.online-example.com systemd[1]: httpd.service: control process exited, code=exited status=127 Apr 04 12:25:16 vps.online-example.com systemd[1]: Failed to start Apache web server managed by cPanel EasyApache. Apr 04 12:25:16 vps.online-example.com systemd[1]: Unit httpd.service entered failed state. Apr 04 12:25:16 vps.online-example.com systemd[1]: httpd.service failed.
    I have already installed package apr and apr-util. Not sure what else to do really. Any help is much appreciated.
    0
  • nyjimbo
    Run "yum -y update". I had the same problem, ran yum again and it resolved the problem for me. Looks like Apache was compiled yesterday and then again today.

    did you run yum to fix the not starting issue or the php issue ?
    0
  • nyjimbo
    as per the first message we seen raw PHP code being rendered. This was solved by resetting the PHP handlers again (for all versions) to suPHP in our case.

    where is this done ?
    0
  • SageBrian
    Run "yum -y update". I had the same problem, ran yum again and it resolved the problem for me. Looks like Apache was compiled yesterday and then again today.

    Yup, that fixed it for me.
    0
  • OttoM
    This did not fix my problem. I run yum -y update twice and re-provisioning with Easy Apache 4. I have no php handlers so it is left as none. When I restarted apache it gives me the following message: /usr/sbin/httpd: symbol lookup error: /usr/sbin/httpd: undefined symbol: apr_stat_fd
    0
  • nyjimbo
    and reprovisioning php handlers.

    can you tell me where this is done ?
    0
  • cPanelNick
    can you tell me where this is done ?

    Please see Software "
  • MultiPHP Manager
  • PHP Handlers (tab) Note: Its the same for v68 as v70
  • 0
  • OttoM
    The following commands did not work for me. [QUOTE] yum clean all yum -y update
    Opened a ticket and it is now solved. thank you
    0
  • OttoM
    This is what I have in /etc/cpupdate.conf by the way. CPANEL=release RPMUP=daily SARULESUP=daily STAGING_DIR=/usr/local/cpanel UPDATES=daily
    0
  • cPanelMichael
    Hello Everyone, Allow me to offer some background information on this topic. An updated ea-apache24 RPM was published yesterday. It was considered a required update and thus automatically installed by the /usr/local/cpanel/scripts/sysup script that runs during the nightly cPanel update process. When an update to an RPM is required, the following settings will not prevent the automatic update from occurring: [QUOTE]
    0
  • John Galvin
    I have this issue, but my 'Operating System Package Updates' settings were set to automatic and I can't change the php handler type in WHM, it's stuck at 'None'. Any other suggestions?
    0
  • Oxy Hospedagem
    Hello, Internal case EA-7366 is open to address an issue where systems with "Operating System Package Updates" set to "Never" in "WHM >> Update Preferences" failed to receive a required update to the ea-apr-util RPM during the most recent EasyApache 4 update. I'll update this thread as soon as the resolution is published. In the meantime, please take the following steps as a temporary workaround: 1. Update to the most recent RPMs available: yum clean all yum update ea-*
    2. Check to see if any of the enabled PHP versions on the system are set to "None" as the PHP handler: /usr/local/cpanel/bin/rebuild_phpconf --current
    3. If any versions are set to "None", browse to "WHM >> MultiPHP Manager" and configure the correct handler for each version. Thank you.

    worked for me, /usr/local/cpanel/bin/rebuild_phpconf --current
    3. If any versions are set to "None", browse to "WHM >> MultiPHP Manager" and configure the correct handler for each version. Thank you.
    Was none I configured as suphp and everything is back
    0
  • cPanelMichael
    I have this issue, but my 'Operating System Package Updates' settings were set to automatic and I can't change the php handler type in WHM, it's stuck at 'None'. Any other suggestions?

    Hi John, Do you happen to know if you were using DSO as the PHP handler for one of the PHP versions on your system? If you are unsure, you can verify that by running a command like this: rpm -qa | grep -i ea-php[0-9][0-9]-php-[0-9]
    If you see an RPM in the output of that command, it means the DSO RPM was installed for that version of PHP. If that's the case, try running the following command: yum reinstall ea-apache24
    Once the RPM is reinstalled, browse back to "WHM >> MultiPHP Manager" to see if you can then update the PHP handlers. Thank you.
    0
  • John Galvin
    rpm -qa | grep -i ea-php[0-9][0-9]-php-[0-9], doesn't give an output. I'm pretty sure it was set to either cgi or suphp. Should I try reinstalling easyapache anyway?
    0
  • cPanelMichael
    Hi John, Yes, try running the following command to see if it helps to make the existing PHP handlers available for assignment: yum reinstall ea-apache24
    If not, can you verify if you are using CloudLinux? Thank you.
    0
  • John Galvin
    Updating easyapache didn't help, it did mark some package as having updates, but not apr or apr-util. I'm running CENTOS 6.9. I had a ticket open with Buy cpanel, but they seem to be stumped as well. Any point opening one direct with cPanel?
    0
  • cPanelMichael
    I had a ticket open with Buy cpanel, but they seem to be stumped as well. Any point opening one direct with cPanel?

    Sure, feel free to open a ticket with us directly and post the ticket number here. I'll update this thread with the outcome once it's solved. Thank you.
    0
  • John Galvin
    Thanks. Your Support Request ID is: 9413007
    0
  • John Galvin
    In case it helps anyone else, I had tried reinstalling apr and apr-util initially and that was causing a conflict. cPanel support sorted it out pretty quickly for me.
    0
  • cPanelMichael
    In case it helps anyone else, I had tried reinstalling apr and apr-util initially and that was causing a conflict. cPanel support sorted it out pretty quickly for me.

    I'm glad to see the issue was solved. Note that in your particular case, the apr and apr-util RPMs installed on your system came from the OS as opposed to the EasyApache 4 YUM repo. Additionally, the CloudLinux apr and apr-util RPMs were installed. Removing the invalid RPMs and reinstalling the ea-apache24, ea-apr, and ea-apr-util RPMs solved the issue. Thank you.
    0
  • Carlos Franco
    Hi there guys, I was also affected by this issue this morning , How can we prevent this happens again? I had my updates to "never update" option... but still got this miss configuration this morning
    0
  • sparek-3
    I had my updates to "never update" option... but still got this miss configuration this morning

    I would second this. Although, I don't seem to have had any issues with this. It's just unnerving that I explicitly have my updates set to manual, so that I won't be taken by surprise with something like this. But it seems cPanel can push out an update to our servers no matter what. And over the years, there have been more than 1 occasion where a cPanel pushed out update wasn't fully thought through and created problems. ... thus why I prefer being in control of updates.
    0
  • vacancy
    I would second this. Although, I don't seem to have had any issues with this. It's just unnerving that I explicitly have my updates set to manual, so that I won't be taken by surprise with something like this. But it seems cPanel can push out an update to our servers no matter what. And over the years, there have been more than 1 occasion where a cPanel pushed out update wasn't fully thought through and created problems. ... thus why I prefer being in control of updates.

    easyapache 4, apache and modules are very easy to keep up to date but at the same time they carry such risks. In easyapache 3, such situations were almost never experienced, because the control was entirely in the system administrator. even if an incorrect update was posted, the system administrator was noticed and corrected until you manually updated it, so it would not be a surprise if you woke up one morning. Easyapache 4 = Always up to date, simpler, surprises. Easyapache 3 = Keeping up to date at your control, harder but no surprises. :)
    0
  • cPanelNick
    We have opened up case CPANEL-19635 to have the system skip EA4 updates if both "cPanel & WHM Updates" and "Operating System Package Updates" are set to "Never Update" We are discussing additional improvements to the update configuration controls and will post another update when we have a path forward.
    0
  • sparek-3
    Well, the EA3 model was pretty stupid. Although, to be fair cPanel tried with this and moved to an RPM model once that became viable. The issue I have, is if I set everything to manual updates, meaning only update when I issue a yum update command myself, then why is something within cPanel issuing a yum update? I don't even have cPanel updates on automatic. Why is this happening? I understand that there are a slew of people out there that will never update anything if they don't have automatic updates enabled. I'm actually fine with having automatic updates on by default. But if I want to be in control of the updates that are issued on my servers, why do I not have that option?
    0

Please sign in to leave a comment.