Post upgrade to Apache 2.4 PHP problems

[matt1206]

Hi,

First post on here after using cPanel for 4 years!

I tried to update my VPS to Apache 2.4 this evening, and it completes the upgrade, and installed PHP 5.4.14 at the same time.

Once done, all my PHP sites break, with errors regarding to preg_match()

OpenCart site:

Warning: preg_match(): Compilation failed: unknown option bit(s) set at offset -1 in /home/z22se/public_html/shop/system/helper/utf8.php on line 155

XenForo site:

Server Error

preg_match(): Compilation failed: unknown option bit(s) set at offset -1

XenForo_Application::handlePhpError()
preg_match() in XenForo/Input.php at line 193
XenForo_Input::_doClean() in XenForo/Input.php at line 179
XenForo_Input->filterSingle() in XenForo/ControllerPublic/Forum.php at line 65
XenForo_ControllerPublic_Forum->actionIndex() in XenKingDir/ControllerPublic/Forum.php at line 19
XenKingDir_ControllerPublic_Forum->actionIndex() in XenForo/FrontController.php at line 310
XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 132
XenForo_FrontController->run() in /home/z22se/public_html/forum/index.php at line 13


I've rolled back to Apache 2.2 andn PHP 5.4.14 and all is working again. I've tried to Google for this, but haven't come across anything so far.

Any suggestions as to what could be breaking?

Thanks,
Matt

 

[KurtN.]

Hi,

First post on here after using cPanel for 4 years!

I tried to update my VPS to Apache 2.4 this evening, and it completes the upgrade, and installed PHP 5.4.14 at the same time.

Once done, all my PHP sites break, with errors regarding to preg_match()

OpenCart site:

Warning: preg_match(): Compilation failed: unknown option bit(s) set at offset -1 in /home/z22se/public_html/shop/system/helper/utf8.php on line 155

XenForo site:

Server Error

preg_match(): Compilation failed: unknown option bit(s) set at offset -1

XenForo_Application::handlePhpError()
preg_match() in XenForo/Input.php at line 193
XenForo_Input::_doClean() in XenForo/Input.php at line 179
XenForo_Input->filterSingle() in XenForo/ControllerPublic/Forum.php at line 65
XenForo_ControllerPublic_Forum->actionIndex() in XenKingDir/ControllerPublic/Forum.php at line 19
XenKingDir_ControllerPublic_Forum->actionIndex() in XenForo/FrontController.php at line 310
XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 132
XenForo_FrontController->run() in /home/z22se/public_html/forum/index.php at line 13


I've rolled back to Apache 2.2 andn PHP 5.4.14 and all is working again. I've tried to Google for this, but haven't come across anything so far.

Any suggestions as to what could be breaking?

Thanks,
Matt

Hi matt1206,

What is the output of the following commands when using Apache 2.2? And when using Apache 2.4?

uname -a
ldd /usr/local/apache/modules/libphp5.so

I understand this isn't an easy request, but I have a sneaking feeling that you may not be linking to the correct version of PCRE. Thus, the only way to tell, is to see the before and after.

Thanks

 

[matt1206]

Hi Kurt,

Currently on Apache 2.2

root@vps [~]# uname -a
Linux vps.z22se.com 2.6.18-308.11.1.el5xen #1 SMP Tue Jul 10 09:29:47 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
root@vps [~]# ldd /usr/local/apache/modules/libphp5.so
        linux-vdso.so.1 =>  (0x00007fff78ad8000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b49bc7ba000)
        libmysqlclient.so.18 => /usr/lib64/libmysqlclient.so.18 (0x00002b49bc9f3000)
        libmcrypt.so.4 => /opt/libmcrypt/lib/libmcrypt.so.4 (0x00002b49bcefa000)
        libltdl.so.3 => /usr/lib64/libltdl.so.3 (0x00002b49bd12b000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b49bd333000)
        libssl.so.6 => /lib64/libssl.so.6 (0x00002b49bd684000)
        libpam.so.0 => /lib64/libpam.so.0 (0x00002b49bd8d2000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b49bdade000)
        libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x00002b49bddea000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002b49bdffb000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b49be220000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002b49be434000)
        libpcre.so.0 => /opt/pcre/lib/libpcre.so.0 (0x00002b49be655000)
        librt.so.1 => /lib64/librt.so.1 (0x00002b49be892000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b49bea9b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b49bed1e000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b49bef23000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b49bf13b000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b49bf369000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b49bf5ff000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b49bf824000)
        libcurl.so.4 => /opt/curlssl/lib/libcurl.so.4 (0x00002b49bfa26000)
        libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b49bfc7f000)
        libxml2.so.2 => /opt/xml2/lib/libxml2.so.2 (0x00002b49bfeb0000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b49c01fb000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b49c0555000)
        libaudit.so.0 => /lib64/libaudit.so.0 (0x00002b49c0771000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b49c098a000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002b49c0b8c000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b49bbd5b000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b49c0d92000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b49c0f9a000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b49c119c000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b49c13b2000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b49c15ca000)

I'll need to wait until later this evening to upgrade to 2.4 again and get the other output.

 

[matt1206]

Just ran the upgrade to Apache 2.4 again

root@vps [~]# ldd /usr/local/apache/modules/libphp5.so
        linux-vdso.so.1 =>  (0x00007fff453fd000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b5fa8687000)
        libmysqlclient.so.18 => /usr/lib64/libmysqlclient.so.18 (0x00002b5fa88c0000)
        libmcrypt.so.4 => /opt/libmcrypt/lib/libmcrypt.so.4 (0x00002b5fa8dc7000)
        libltdl.so.3 => /usr/lib64/libltdl.so.3 (0x00002b5fa8ff8000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b5fa9200000)
        libssl.so.6 => /lib64/libssl.so.6 (0x00002b5fa9551000)
        libpam.so.0 => /lib64/libpam.so.0 (0x00002b5fa979f000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b5fa99ab000)
        libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x00002b5fa9cb7000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002b5fa9ec8000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b5faa0ed000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002b5faa301000)
        libpcre.so.0 => /opt/pcre/lib/libpcre.so.0 (0x00002b5faa522000)
        librt.so.1 => /lib64/librt.so.1 (0x00002b5faa75f000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b5faa968000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b5faabeb000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b5faadf0000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b5fab008000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b5fab236000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b5fab4cc000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b5fab6f1000)
        libcurl.so.4 => /opt/curlssl/lib/libcurl.so.4 (0x00002b5fab8f3000)
        libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5fabb4c000)
        libxml2.so.2 => /opt/xml2/lib/libxml2.so.2 (0x00002b5fabd7d000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b5fac0c8000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b5fac422000)
        libaudit.so.0 => /lib64/libaudit.so.0 (0x00002b5fac63e000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b5fac857000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002b5faca59000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b5fa7c28000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b5facc5f000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b5face67000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b5fad069000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b5fad27f000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b5fad497000)
root@vps [~]# httpd status

              Apache Server Status for localhost (via 127.0.0.1)

   Server Version: Apache/2.4.4 (Unix) OpenSSL/0.9.8e-fips-rhel5
          mod_bwlimited/1.4 PHP/5.4.14

   Server Built: Apr 18 2013 00:08:07
     _________________________________________________________________

   Current Time: Thursday, 18-Apr-2013 00:13:20 BST
   Restart Time: Thursday, 18-Apr-2013 00:12:15 BST
   Parent Server Config. Generation: 1
   Parent Server MPM Generation: 0
   Server uptime: 1 minute 5 seconds
   Server load: 0.79 1.22 0.68
   Total accesses: 76 - Total Traffic: 411 kB
   CPU Usage: u1.93 s.35 cu0 cs0 - 3.51% CPU load
   1.17 requests/sec - 6.3 kB/second - 5.4 kB/request
   2 requests currently being processed, 8 idle workers

_.____W_._C._...................................................
................................................................
......................

   Scoreboard Key:
   "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
   "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
   "C" Closing connection, "L" Logging, "G" Gracefully finishing,
   "I" Idle cleanup of worker, "." Open slot with no current process

 

[NovemberRain]

This was reported several times, I had a ticket on this but they haven't been able to fix it since 2.4 was introduced in easy apache.

http://forums.cpanel.net/f442/new-s...r-pcre-not-compiled-utf-8-support-325662.html
http://forums.cpanel.net/f442/php-f...es-after-latest-easyapache-update-321381.html

 

[KurtN.]

Hi matt1206,

I just deleted my prior post. It seemed my previous remark (that I deleted) was incorrect.
However, if you could, would you please submit a ticket with support so that this can be tracked? Then post your ticket ID here so that I will be able to follow it.

Thank you for very much for your help,
Kurt

 

[matt1206]

Thanks Kurt.

Ticket ID: 4010073

Regards,
Matt

 

[TheVisitors]

I'm interested to know if this was resolved or can be resolved.

 

[KurtN.]

At the moment, there doesn't seem to be an obvious fix for this. Nor am I able to duplicate this on my own device.
I'll try some other ways to duplicate this issue in the near future. If so, I'll create a case so it can be tracked internally.

Sorry I don't have better news.

 

[matt1206]

I recently moved servers to a new CentOS 6.4 64bit build, and I've just tried an update to Apache 2.4

Exactly the same errors!

XenForo
preg_match(): Compilation failed: unknown option bit(s) set at offset 0


phpBB3
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions_content.php on line 712: preg_replace(): Compilation failed: unknown option bit(s) set at offset 0

Looks like I'll be staying with Apache 2.2 for the foreseeable future.

 

[NovemberRain]

It's sad they still can't fix it. I don't think they are even working on it actually. It's been a long time. We can't use 2.4 because of this issue.

 

[rlshosting]

Expat breaks under Apache 2.4 and Centos 5 64-Bit.

 

[lbeachmike]

So to ask a really dumb question, if this issue is a known issue, why does EasyApache still offer the option for me to upgrade to Apache 2.4 without any warnings that it will break the websites of most of my users? It looks like the issue has been known for at least four months. I was going to try upgrading, but decided to first check around the forums and see if anybody ran into any issues. If I had not done that, why should users spend time upgrading to discover issues that are already known and don't yet have a fix? Why not push out a warning or email out a warning or disable the functionality until it is fixed?

Am I missing something?

 

[Duplika]

I agree with @Ibeachmike. Maybe bring the experimental tag again to discourage people from upgrading yet?

 

[cPanelMichael]

Hello

This is discussed on the following thread:

PCRE problems

Thank you.

 

[lbeachmike]

Hello

This is discussed on the following thread:

PCRE problems

Thank you.

I think you've missed the point. Many of us, perhaps most of us, are not looking for DIY fixes - we want to know that when we choose to use functionality in the product that is no longer listed as Experimental, that the functionality will actually work as advertised. That it will work reliably. Reliability is an essential ingredient for your product.

My concern is that you have this functionality in the product and removed the experimental tag, yet it does not work. If I had not decided to check the forum first, I would have been in for a stressful night or would have wasted my time, which I have no excess of right now.

Even your upgrade documentation page says nothing of this issue.

Are my concerns clear? Is it fair to say that the status of this functionality is still essentially Experimental?

 

[cPanelMichael]

My intention was to direct users to the post on the other thread where an update was provided. While manual workarounds are available, that specific post notes that an internal case has been opened to address the issue. You are correct that Apache 2.4 is no longer in "Experimental" mode. DSO in combination with applications that require PCRE is not an uncommon configuration, so your concerns are valid. This very point has been noted in the internal case, so our developers have been made aware of it. Thank you for your input on the matter.

 

[lbeachmike]

My intention was to direct users to the post on the other thread where an update was provided. While manual workarounds are available, that specific post notes that an internal case has been opened to address the issue. You are correct that Apache 2.4 is no longer in "Experimental" mode. DSO in combination with applications that require PCRE is not an uncommon configuration, so your concerns are valid. This very point has been noted in the internal case, so our developers have been made aware of it. Thank you for your input on the matter.

Thanks Michael. My primary point is more of a question -

If the issue has been known about for four+ months, and there have since been additional WHM updates, why not retag this as Experimental or provide warning inside the product of the known issue? Or at least on the apache upgrade documentation page? You're relying on people finding the thread before they attempt their upgrade, so for those who don't, why not avoid these people the extra grief?

I will tune into the other thread, because I do wish to know if the functionality works without issue when not running in DSO mode. For example, I run in suphp, so does that mean that the upgrade would work on my servers?

Thanks.

 

[cPanelMichael]

If the issue has been known about for four+ months, and there have since been additional WHM updates, why not retag this as Experimental or provide warning inside the product of the known issue?

Yes, this was brought up in the internal case. It's likely this will happen if a resolution is not implemented right away.

I will tune into the other thread, because I do wish to know if the functionality works without issue when not running in DSO mode. For example, I run in suphp, so does that mean that the upgrade would work on my servers?

Thus far, the issue has only been reproduced when the PHP handler is set to DSO.

Thank you.

 

[ScottTh]

Hi all,

Thank you all for the helpful feedback and discussion. The EasyApache team will be discussing the Apache 2.4 issues reported in this thread. After discussion we will be able to prioritize possible solutions.

Thank you all and I'll keep this thread updated with our progress and ideas.