[PHP-BUG] Bug #65791 [NEW]: Mixing header('Status', and other header with int $http_response_code
From: rainer-phpbugs at 7val dot com
Operating system:
PHP version: 5.4.20
Package: HTTP related
Bug Type: Bug
Bug description:Mixing header('Status', and other header with int
$http_response_code
Description:
The int $http_response_code for later calls to header() don't update any
earlier codes set with header('Status: ???'). The Documentation claims that
it "Forces the HTTP response code to the specified value". If
header('Status: ...') has not been used beforehand, setting
http_response_code works as expected.
Test script:
---
https://bugs.php.net/bug.php?id=65791&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65791&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65791&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65791&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65791&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65791&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65791&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65791&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65791&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65791&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65791&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65791&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65791&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65791&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65791&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65791&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65791&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65791&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65791&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65791&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65791&r=mysqlcfg
[PHP-BUG] Bug #61867 [NEW]: user_ini_filename ignored for cached user_config
From: Operating system: Linux PHP version: 5.3.11 Package: FPM related Bug Type: Bug Bug description:user_ini_filename ignored for cached user_config Description: I would like to use multiple different user.ini-Files in the same directory to modify some php.ini settings. I'm using Apache with mod_fastcgi, and therefore, as far as I can tell, I can't insert line breaks into variables with setenv, and teherefore I'm limited to at most one PHP_VALUE that I can define per vhost. This would be sufficient to set user_ini.filename to a suitable different file and set any values in there. However, php_cgi_ini_activate_user_config() in sapi/fpm/fpm/fpm_main.c only evaluates the path, not the current value of user_ini_filename when retrieving cached entries. As a result, all requests hitting a given instance within the expiry period will receive the values valid for the user_ini.filename specified in the first request, which may or may not be the same as the one defined for the current request. -- Edit bug report at https://bugs.php.net/bug.php?id=61867&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61867&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61867&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61867&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61867&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61867&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61867&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61867&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61867&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61867&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61867&r=support Expected behavior: https://bugs.php.net/fix.php?id=61867&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61867&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61867&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61867&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61867&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61867&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61867&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61867&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61867&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61867&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61867&r=mysqlcfg
Bug #61867 [Opn]: user_ini_filename ignored for cached user_config
Edit report at https://bugs.php.net/bug.php?id=61867&edit=1 ID: 61867 User updated by:rainer-phpbugs at 7val dot com Reported by:rainer-phpbugs at 7val dot com Summary:user_ini_filename ignored for cached user_config Status: Open Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.11 Block user comment: N Private report: N New Comment: Another related issue is that PHP_VALUES passed via the fcgi-interface are also cached. If I set e.g. memory_limit to a different Value than the one specified in php.ini in one vhost via PHP_VALUE, the next request for an entirely different vhost that just happens to be processed by the same php-fpm child will receive this non-default value. Previous Comments: [2012-04-27 16:41:00] rainer-phpbugs at 7val dot com Description: I would like to use multiple different user.ini-Files in the same directory to modify some php.ini settings. I'm using Apache with mod_fastcgi, and therefore, as far as I can tell, I can't insert line breaks into variables with setenv, and teherefore I'm limited to at most one PHP_VALUE that I can define per vhost. This would be sufficient to set user_ini.filename to a suitable different file and set any values in there. However, php_cgi_ini_activate_user_config() in sapi/fpm/fpm/fpm_main.c only evaluates the path, not the current value of user_ini_filename when retrieving cached entries. As a result, all requests hitting a given instance within the expiry period will receive the values valid for the user_ini.filename specified in the first request, which may or may not be the same as the one defined for the current request. -- Edit this bug report at https://bugs.php.net/bug.php?id=61867&edit=1
[PHP-BUG] Req #62947 [NEW]: Unneccesary warnings when phpfpm is started with the configured user/group
From: rainer-phpbugs at 7val dot com Operating system: all PHP version: 5.3.16 Package: FPM related Bug Type: Feature/Change Request Bug description:Unneccesary warnings when phpfpm is started with the configured user/group Description: phpfpm warns that the "'user' directive is ignored when FPM is not running as root", even when the user or group is already correct, e.g. if the user "www-data" starts phpfpm, and the "user" directive is set to www-data. -- Edit bug report at https://bugs.php.net/bug.php?id=62947&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62947&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62947&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62947&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62947&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62947&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62947&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62947&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62947&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62947&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62947&r=support Expected behavior: https://bugs.php.net/fix.php?id=62947&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62947&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62947&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62947&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62947&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62947&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62947&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62947&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62947&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62947&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62947&r=mysqlcfg
[PHP-BUG] Req #62948 [NEW]: apache_child_terminate() for FPM
From: rainer-phpbugs at 7val dot com Operating system: all PHP version: 5.3.16 Package: FPM related Bug Type: Feature/Change Request Bug description:apache_child_terminate() for FPM Description: Occasionally, out web servers have to process large amounts of data, resulting in php-fpm children that occupy > 500MB of RAM, which is not returned to the OS after the request has finished. Since we know precisely when this happens, it would be useful to let the affected php-fpm child die after the request, similar to apache_child_terminate(). -- Edit bug report at https://bugs.php.net/bug.php?id=62948&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62948&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62948&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62948&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62948&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62948&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62948&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62948&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62948&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62948&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62948&r=support Expected behavior: https://bugs.php.net/fix.php?id=62948&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62948&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62948&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62948&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62948&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62948&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62948&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62948&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62948&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62948&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62948&r=mysqlcfg
[PHP-BUG] Req #62949 [NEW]: Automatically terminate php-fpm children that exceed a memory usage limit
From: rainer-phpbugs at 7val dot com Operating system: all PHP version: Irrelevant Package: FPM related Bug Type: Feature/Change Request Bug description:Automatically terminate php-fpm children that exceed a memory usage limit Description: As an alternative fix for the bloated php-fpm children descibed in #62948, it would be nice to be able to configure a memory limit. If a php-fpm process exceeds this limit after a request has finished processing, the child is terminated automatically. -- Edit bug report at https://bugs.php.net/bug.php?id=62949&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62949&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62949&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62949&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62949&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62949&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62949&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62949&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62949&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62949&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62949&r=support Expected behavior: https://bugs.php.net/fix.php?id=62949&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62949&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62949&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62949&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62949&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62949&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62949&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62949&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62949&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62949&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62949&r=mysqlcfg
[PHP-BUG] Req #62951 [NEW]: Log utime and stime
From: rainer-phpbugs at 7val dot com
Operating system:
PHP version: 5.3.16
Package: FPM related
Bug Type: Feature/Change Request
Bug description:Log utime and stime
Description:
To identify performance bottlenecks in our shared hosting environment, it
is desirable to log the utime and stime consumed for each request. The
current %{system}C and %{user}C just log the relative CPU-Usage percentage,
not the absolute time used.
the patch below adds %(rsystem}C and %{ruser}C to the logformat options,
measured in milliseconds via getrusage();
--
Edit bug report at https://bugs.php.net/bug.php?id=62951&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62951&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62951&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62951&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62951&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62951&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62951&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62951&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62951&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62951&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62951&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62951&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62951&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62951&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62951&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62951&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62951&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62951&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62951&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62951&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62951&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62951&r=mysqlcfg
Bug #62954 [Com]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954&edit=1
ID: 62954
Comment by: rainer-phpbugs at 7val dot com
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about
20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3
(no problem after more than 2000 restarts each).
remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me.
gdb backtraces of the hanging process always look like this (taken on opensuse
11 i386):
#0 0xe424 in __kernel_vsyscall ()
#1 0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6
#3 0xb4f74a66 in free () from /lib/libc.so.6
#4 0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5 0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
#6 0xb4f3089f in __run_exit_handlers () from /lib/libc.so.6
#7 0xb4f308fd in exit () from /lib/libc.so.6
#8 0x084c382f in fpm_signals_sighandler_exit_ok (pid=10) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_signals.c:254
#9
#10 0xb4f70701 in _int_free () from /lib/libc.so.6
#11 0xb4f74a6d in free () from /lib/libc.so.6
#12 0x08426de0 in zend_hash_destroy (ht=0x891088c) at
build/src/external/php-5.3.16/Zend/zend_hash.c:532
#13 0x08404762 in destroy_zend_class (pce=0x8911cb4) at
build/src/external/php-5.3.16/Zend/zend_opcode.c:206
#14 0x08426dc8 in zend_hash_destroy (ht=0x87aa490) at
build/src/external/php-5.3.16/Zend/zend_hash.c:529
#15 0x08414ed7 in zend_shutdown () at
build/src/external/php-5.3.16/Zend/zend.c:762
#16 0x083a84da in php_module_shutdown () at
build/src/external/php-5.3.16/main/main.c:2210
#17 0x084bf608 in fpm_php_cleanup (which=2, arg=0x0) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_php.c:199
#18 0x084b5f0c in fpm_cleanups_run (type=2) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_cleanup.c:45
#19 0x084c6c73 in fpm_unix_init_main () at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_unix.c:340
#20 0x084b4fe8 in fpm_init (argc=3, argv=0xbffb2fe4, config=0xbffb50a5
"conf/php-fpm.conf", prefix=0x0, pid=0x0, test_conf=0,
run_as_root=0) at build/src/external/php-5.3.16/sapi/fpm/fpm/fpm.c:59
#21 0x084be0f5 in main (argc=3, argv=0xbffb2fe4) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_main.c:1805
Previous Comments:
[2012-09-05 07:25:26] jonas at brachium-system dot net
@David: Can you please explain, why an NGINX configuration option will solve
that startup problem?
[2012-09-02 19:47:46] david at appliedautonomics dot com
Fixed on Debian Squeez via adding to fastcgi params:
fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;
[2012-09-02 16:43:24] per at techspot dot com
This bug occurs more frequently on heavily loaded websites.
On my testserver it is difficult to reproduce with a low load.
But on my live server doing a "service php-fpm restart" makes it fail most
times.
For some reason the problem occurs less frequently in php-fpm 5.4.6 vs 5.3.16
opcode cachers also makes it occur more frequently, but it's possible to
reproduce with no opcode cacher loaded aswell, same rules as above for
frequency still apply (5.3 vs 5.4)
Output from testserver below running CentOS v6.3 with all patches applied and
php v5.4 via the remi repository:
http://rpms.famillecollet.com/enterprise/6/test/x86_64/
# php -v
PHP 5.4.6 (cli) (built: Aug 16 2012 14:26:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo
# DAEMON_COREFILE_LIMIT=unlimited strace -s1024 -f /etc/init.d/php-fpm restart
2>&1 | grep -i SEGV
[pid 3017] rt_sigaction(SIGSEGV, {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, {SIG_DFL, [], 0}, 8) = 0
[pid 3017] rt_sigaction(SIGSEGV, {SIG_DFL, [SEGV], SA_RESTORER|SA_RESTART,
0x7fdddb55a920},
[pid 3017] <... rt_sigaction resumed> {0x7fddd5050730, [SEGV],
SA_RESTORER|SA_RESTART, 0x7fdddb55a920}, 8) = 0
[2012-09-02 09:07:29] jonas at brachium-system dot net
PHP 5.3.16-dev (fpm-fcgi) (built: Sep 2 2012 04:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
I have tried it with the current branch PHP-5.3.
It started two times correctly (S
Req #62951 [Com]: Log utime and stime
Edit report at https://bugs.php.net/bug.php?id=62951&edit=1
ID: 62951
Comment by: rainer-phpbugs at 7val dot com
Reported by:rainer-phpbugs at 7val dot com
Summary:Log utime and stime
Status: Feedback
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
I've missed the bit in fpm_log.c, since I didn't want to include my changes
that cause tms_total to always be in 1/1000 seconds. The updated Patch includes
this change.
Previous Comments:
[2012-09-27 14:33:32] f...@php.net
the patch does not seem to be complete. There's a missing part: how the log is
handle ?
[2012-08-27 14:13:19] rainer-phpbugs at 7val dot com
Description:
To identify performance bottlenecks in our shared hosting environment, it is
desirable to log the utime and stime consumed for each request. The current
%{system}C and %{user}C just log the relative CPU-Usage percentage, not the
absolute time used.
the patch below adds %(rsystem}C and %{ruser}C to the logformat options,
measured in milliseconds via getrusage();
--
Edit this bug report at https://bugs.php.net/bug.php?id=62951&edit=1
Req #62949 [Wfx]: Automatically terminate php-fpm children that exceed a memory usage limit
Edit report at https://bugs.php.net/bug.php?id=62949&edit=1 ID: 62949 User updated by:rainer-phpbugs at 7val dot com Reported by:rainer-phpbugs at 7val dot com Summary:Automatically terminate php-fpm children that exceed a memory usage limit Status: Wont fix Type: Feature/Change Request Package:FPM related Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: There's a nice (but admittedly non-trivial, and for the current resident set size, not elegant) example how to measure memory usage at http://nadeausoftware.com/articles/2012/07/c_c_tip_how_get_process_resident_set_size_physical_memory_use Previous Comments: [2012-09-27 14:41:40] f...@php.net this have been discusses many times and it's not possible as it's very complicated to mesure the memory consume by one process: memory from external libraries, if children have been forked, ... the only thing we have is the memory_limit in php which only mesure the memory allocated from PHP itself. [2012-08-27 12:52:24] rainer-phpbugs at 7val dot com Description: As an alternative fix for the bloated php-fpm children descibed in #62948, it would be nice to be able to configure a memory limit. If a php-fpm process exceeds this limit after a request has finished processing, the child is terminated automatically. -- Edit this bug report at https://bugs.php.net/bug.php?id=62949&edit=1
