[Case 58625] PCRE problems

[simonas]

Hi,

Centos 6 x64 server, updates, WHM 11.38.0 (build 7)

After installing Apache 2.4.4 and PHP 5.4.14 -PCRE issues:

System has:

pcretest -C
PCRE version 8.32 2012-11-30
Compiled with
8-bit support
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

PHP uses:

PCRE Library Version 7.8 2008-09-05

All installed:

rpm -qa | grep pcre
cpanel-pcre-8.31-1.cp1136.x86_64
pcre-devel-7.8-6.el6.x86_64
pcre-7.8-6.el6.x86_64

Users are having a lot of problems due to the old PCRE version being used, like:
preg_replace(): Compilation failed: unknown option bit(s) set at offset 0
preg_split(): Compilation failed: unknown option bit(s) set at offset 0

That means popular software, like SMF , Wordpress will not work correctly.

How this could be fixed. How to tell PHP use Cpanel's PCRE version?

Thanks

 

[simonas]

Anybody? I found about 10 similar threads on this forum with no answers.
More and more people will encounter same issue.

Thanks

 

[simonas]

No help from support:

Hello,

Thanks for contacting us. Unfortunately, we don't have support for this newer version of PCRE in EasyApache. You'll notice in phpinfo that the version of PCRE that PHP is compiled against is stored in /opt, so the system version of PCRE is not relevant. EasyApache is maintained with a specific version in mind, so it manages the version installed in /opt, and applies some patches against it when compiling. If you were to put a newer version of PCRE in /opt, EasyApache would overwrite it.

You can submit a feature request for this at cPanel Feature Requests. I did a cursory search and did not find a request for this that already exists.

Thank you for your understanding.

Fixed it myself:

echo "/opt/pcre/lib/" >> /etc/ld.so.conf

And rebuild EasyApache.

I did more, cleaned, tested, investigated, but the above should do the trick.

 

[cPanelMichael]

Hello

I am happy to hear you were able to find a manual workaround. It's still a good idea to submit a feature request for a newer version at:

Submit A Feature Request

Thank you.

 

[simonas]

Hey, Michael,

I believe it's more a bug than a feature.

Cpanel or EasyApache installs PCRE version 8.21 2011-12-12 int /opt/pcre/lib

But it does also install PCRE from YUM repository, which for Centos has Version 7.8 2008-09-05, which is too old.

I am not sure why EasyApache makes Apache and PHP (DSO, mod_ruid2) to use the system ones, even when it's compiled with /opt/pcre parameter.

Requesting PCRE version from command lines reports new version, but using phpinfo() reported old versions. Meaning apache , and PHP running as module uses system ones.

As i have little time nowadays, let's se if another users will encouter same problem, maybe they could provide more information.

 

[epaslv]

Hello

I am happy to hear you were able to find a manual workaround. It's still a good idea to submit a feature request for a newer version at:

Submit A Feature Request

Thank you.

When you update apache to Apache 2.4.4 and build via PHP (DSO, mod_ruid2) it uses system version of pcre and not the one compiled --with-pcre-regex=/opt/pcre

pcretest -C PCRE
/opt/pcre/bin/pcretest -C PCRE

I happens on all of our servers, It would be nice to acknowledge this as a problem.

 

[cPanelMichael]

When you update apache to Apache 2.4.4 and build via PHP (DSO, mod_ruid2) it uses system version of pcre and not the one compiled --with-pcre-regex=/opt/pcre

pcretest -C PCRE
/opt/pcre/bin/pcretest -C PCRE

I happens on all of our servers, It would be nice to acknowledge this as a problem.

Could you submit a bug report for this issue so we can investigate this issue and open an internal case with our developers if necessary? You can submit a bug report via:

Submit A Bug Report

Please provide us with the ticket number you are assigned so we can keep this thread updated.

Thank you.

 

[epaslv]

Could you submit a bug report for this issue so we can investigate this issue and open an internal case with our developers if necessary? You can submit a bug report via:

Submit A Bug Report

Please provide us with the ticket number you are assigned so we can keep this thread updated.

Thank you.

Request id is: 4165457

Interesting observation, when PHP 5 Handler is switched to "cgi" all appears ok.

Switch it to "dso" and you get errors as per below

preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Compilation failed: unknown option bit(s) set at offset -1
preg_replace() [<a href='function.preg-replace'>function.preg-replace</a>]: Compilation failed: unknown option bit(s) set at offset -1

 

[dmacleo]

just caught this today myself with a 48hr old cent 6.4 and cpanel install after swapping to mod_ruid.
trying the fix above today, swapping to fcgid does work though.

 

[cPanelMichael]

Request id is: 4165457

The issue was resolved on this particular ticket with the use of the following command:

# ldconfig

This updated the library cache after the custom changes that were made to /etc/ld.so.conf from the manual workaround previously attempted by the user. After running this command, another instance of EasyApache completed successfully and no further issues were detected after that.

Thank you.

 

[dmacleo]

The issue was resolved on this particular ticket with the use of the following command:

# ldconfig

This updated the library cache after the custom changes that were made to /etc/ld.so.conf from the manual workaround previously attempted by the user. After running this command, another instance of EasyApache completed successfully and no further issues were detected after that.

Thank you.

I will try that, thanks

 

[simonas]

As of WHM 11.38.2 (build 3) with Easy::Apache v3.22.6 the problem still exists.

Developers, please fix this issue, so that mod_ruid2 would use PCRE from /opt/pcre, not the outdated YUM ones.

EDIT: also MOD SECURITY reports this:

[:notice] [pid 12121] ModSecurity: PCRE compiled version="8.21 "; loaded version="7.8 2008-09-05"
[:warn] [pid 12121] ModSecurity: Loaded PCRE do not match with compiled!

Meanwhile users can fix this manually.
Recommended to do this on new server before compiling EasyApache (as you'll need to recompile after fix).

Run this:

echo "/opt/pcre/lib/" >> /etc/ld.so.conf 
ldconfig

And (re)compile EasyApache.

After this check which version of PCRE php uses. It should be:
PCRE Library Version 8.21 2011-12-12

 

[cPanelMichael]

Our developers are aware of this issue, and an internal case is open to address it. For reference, the internal case number is 58625. Our development team is still researching the issue at this time, so there is currently no specific time frame available on when a resolution may be implemented.

I have made a note to update this thread with more information as it becomes available.

Thank you.

 

[kubekarre]

Hello guys, any update on this ? I have used the custom fix above, but any idea when a fix will be implemented in easy apache?

 

[cPanelMichael]

Hello guys, any update on this ? I have used the custom fix above, but any idea when a fix will be implemented in easy apache?

It's an active case that our EasyApache team is aware of. There is no specific time frame available on when a resolution will be implemented into EasyApache as this time.

Thank you.

 

[yatesf]

[:notice] [pid 12121] ModSecurity: PCRE compiled version="8.21 "; loaded version="7.8 2008-09-05"
[:warn] [pid 12121] ModSecurity: Loaded PCRE do not match with compiled!

I've been repeatedly getting these same errors in the apache error log. I have not officially reported/documented it in a cPanel ticket though. Count me in though, as a person who also wishes to have this bug fixed in future versions.

Run this:

echo "/opt/pcre/lib/" >> /etc/ld.so.conf 
ldconfig

And (re)compile EasyApache.

I implemented the above fix for a temporary solution, but instead of (re)compiling EasyApache, I was able to just run the following two commands instead for successful error resolution:

/scripts/rebuildhttpdconf
service httpd restart

 

[simonas]

Well let's hope after a major 11.40 update they will have more time fixing smaller bugs.

 

[ScottTh]

Well let's hope after a major 11.40 update they will have more time fixing smaller bugs.

Hi simonas,

This case is on the EasyApache team's to-do list. We're working hard on a multitude of new features and fixes at the moment. We hope to have this fix available to everyone in the near future.

Thank you!

 

[tandyuk]

Hi simonas,

This case is on the EasyApache team's to-do list. We're working hard on a multitude of new features and fixes at the moment. We hope to have this fix available to everyone in the near future.

Thank you!

I just hit this issue on a brand new centos 6.4 VPS.
May I suggest it gets moved MUCH higher up the easyapache teams TODO list,
Like AT THE DAMN TOP!

I couldn't give a crap about new features while the existing features don't work properly.

I look forward to this simple fix being included in easyapache within the next few DAYS!

 

[tomdchi]

I wouldn't hold your breath waiting on cPanel to fix this quickly. It will likely be months if not end of 2014 before it is resolved.