Bug 730078
Summary: | httpd process hang in futex() - from __tz_convert | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Orion Poplawski <orion> |
Component: | php | Assignee: | Remi Collet <rcollet> |
Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.1 | CC: | prc, rcollet, syeghiay |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-09-27 13:45:26 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Orion Poplawski
2011-08-11 17:39:01 UTC
Thanks for the report. This is php issue; if you have a core dump and could install php-debuginfo ("debuginfo-install php") and attach the backtrace with that installed, it might shed a little more light. This part of the backtrace: #15 0x0580413a in zend_error () from /etc/httpd/modules/libphp5.so #16 0x057f6f5b in zend_timeout () from /etc/httpd/modules/libphp5.so #17 <signal handler called> #18 0x00289416 in __kernel_vsyscall () #19 0x004558a3 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #20 0x003f337b in _IO_new_file_underflow (fp=0x1f19358) at fileops.c:598 shows a signal handler interrupting the script; probably the max_execution_time timer expiring. This process is not signal-safe, and has in this case triggered a deadlock by trying to re-enter tzset(), which was already executing further down the stack. This is essentially a design flaw in PHP, and is "non-trivial" to fix. If you can reproduce this, and work out why the script is running for longer than the execution time, fixing that would be the simplest way to avoid the problem. (if you go up the stack to a frame inside httpd, you can print r->filename to discover what script is running, and r->args to find the query string) Alternatively, you can increase the max_execution_time to avoid triggering the signal, if that is feasible. Joe - Thanks a lot for the detailed analysis. It is indeed a php script hitting the max_execution_time limit. I've upped the limit for now to try to help. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. As this is a general design issue with signal handling in php and as workaound is known (setting max_execution_time to avoid trigerring the signal), closing that bug. If you still face problems with this issue, please let us know. |