Bug #60629 [Com]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Comment by: f...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
it's on my todo list. I'll try to take time to look at this bugs this week.
++ jerome
Previous Comments:
[2012-01-03 12:12:09] larue...@php.net
fat, could you plz look at this? thanks
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60629 [PATCH]: memory corruption when web server closed the fcgi fd(?)
Edit report at https://bugs.php.net/bug.php?id=60629&edit=1
ID: 60629
Patch added by: f...@php.net
Reported by:phpbugs at oops dot mooo dot com
Summary:memory corruption when web server closed the fcgi
fd(?)
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Squeeze
PHP Version:5.3.9RC4
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-bugs-60629.patch
Revision: 1325613774
URL:
https://bugs.php.net/patch-display.php?bug=60629&patch=fpm-bugs-60629.patch&revision=1325613774
Previous Comments:
[2012-01-03 12:13:34] f...@php.net
it's on my todo list. I'll try to take time to look at this bugs this week.
++ jerome
[2012-01-03 12:12:09] larue...@php.net
fat, could you plz look at this? thanks
[2011-12-30 23:40:43] phpbugs at oops dot mooo dot com
I think it might've been introduced in this commit (~line 270).
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c?r1=317894&r2=317897
It looks like write() might have the same problem, since it returns a ssize_t
that's casted to size_t.
Fix might be to use ssize_t instead?
[2011-12-30 23:12:00] phpbugs at oops dot mooo dot com
Description:
I tried php5.3.9RC4 today and got a few core dumps.
I think b)fcgi_flush() returns false, making fcgi_write return -1. Then
sapi_cgibin_single_write will make it positive because ret is unsigned in c).
As a result, the comparison in d) will fail.
In debugger it looks like PHP is looping over open_packet() in an infinite
loop. Each time out_pos gets increased a little. Finally, after overwriting the
whole stack, it will SIGSEGV.
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fastcgi.c
===
int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, int
len)
{
int limit, rest;
if (len <= 0) {
return 0;
}
if (req->out_hdr && req->out_hdr->type != type) {
close_packet(req);
}
/* Optimized version */
limit = sizeof(req->out_buf) - (req->out_pos - req->out_buf);
if (!req->out_hdr) {
limit -= sizeof(fcgi_header);
if (limit < 0) limit = 0;
}
if (len < limit) {
if (!req->out_hdr) {
open_packet(req, type);
}
memcpy(req->out_pos, str, len);
req->out_pos += len;
} else if (len - limit < sizeof(req->out_buf) - sizeof(fcgi_header)) {
if (!req->out_hdr) {
a) open_packet(req, type);
}
if (limit > 0) {
memcpy(req->out_pos, str, limit);
req->out_pos += limit;
}
if (!fcgi_flush(req, 0)) {
b) return -1;
}
===
https://svn.php.net/repository/php/php-src/tags/php_5_3_9RC4/sapi/fpm/fpm/fpm_main.c
===
static inline size_t sapi_cgibin_single_write(const char *str, uint str_length
TSRMLS_DC)
{
c) size_t ret;
/* sapi has started which means everyhting must be send through fcgi */
if (fpm_is_running) {
fcgi_request *request = (fcgi_request*) SG(server_context);
ret = fcgi_write(request, FCGI_STDOUT, str, str_length);
d) if (ret <= 0) {
return 0;
}
return ret;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60629&edit=1
Bug #60763 [Com]: Access denied. when file extension is .html
Edit report at https://bugs.php.net/bug.php?id=60763&edit=1
ID: 60763
Comment by: f...@php.net
Reported by:nbari at dalmp dot com
Summary:Access denied. when file extension is .html
Status: Closed
Type: Bug
Package:FPM related
Operating System: FreeBSD / Mac OS
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Be aware that FPM is marked as *experimental* on 5.3.x. Which means that
changes
can break configurations between release.
It's the case between 5.3.8 and 5.3.9 as the security.limit_extensions
configuration item has been added and it defaults to .php. If you need to
execute
other extensions, you have to change this setting.
++ fat
Note: the experimental flag has been removed in 5.4.x.
Previous Comments:
[2012-01-16 21:52:14] dmilith at gmail dot com
It also happens on Debian Lenny. It's not system related.
[2012-01-16 00:06:38] nbari at dalmp dot com
php 5.3.9 adds support to chose what extensions to parse
the solution was to add the next line the php-fpm.conf
security.limit_extensions = .php .html
[2012-01-15 23:27:57] nbari at dalmp dot com
Description:
When serving .html files as php an "Access denied." is displayed instead of the
properly parsed page.
With php versions <= 5.3.8 the following configuration example works for nginx
--
server {
server_name domain.tpl *.domain.tld;
root /home/sites/domain.tld/home/html;
location ~ \.(php|htm|html)$ {
fastcgi_pass unix:/tmp/php-fpm.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
includefastcgi_params;
}
}
--
files on /home/sites/domain.tld/home/html are:
http://domain.tld/index.html <--- does not work with php-5.3.9 display an
Access
denied.
http://domain.tld/test.php <--- works
Expected result:
properly parse the .html and display the content.
Actual result:
--
Access denied.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60763&edit=1
Bug #60933 [Com]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1
ID: 60933
Comment by: f...@php.net
Reported by:m...@php.net
Summary:Testing asort with SORT_LOCALE_STRING fails on Mac
OS X 10.6
Status: Open
Type: Bug
Package:Arrays related
Operating System: Mac OS X 10.6
PHP Version:5.4SVN-2012-01-30 (SVN)
Block user comment: N
Private report: N
New Comment:
Works on FreeBSD 8.2-RELEASE with snap php5.4-201202011030
PASS Sort with SORT_LOCALE_STRING [ext/standard/tests/array/locale_sort.phpt]
Previous Comments:
[2012-02-01 03:58:53] carloschilazo at gmail dot com
I think this goes waaay back to: 41758
And bug 41758 is in status Won't fix, I couldn't find why.
Is there a reason behind this?
Thanks
[2012-01-30 13:50:47] m...@php.net
Description:
The test ext/standard/tests/array/locale_sort.phpt fails.
"Ãle-du-Prince-Ãdouard"
is sorted to the end of the array, instead of the expected 3rd position.
Test script:
---
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Ãcosse",
"ON" => "Ontario",
"PE" => "Ãle-du-Prince-Ãdouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
Expected result:
array(13) {
["AB"]=>
string(7) "Alberta"
["BC"]=>
string(20) "Colombie-Britannique"
["PE"]=>
string(21) "Ãle-du-Prince-Ãdouard"
["MB"]=>
string(8) "Manitoba"
["NB"]=>
string(17) "Nouveau-Brunswick"
["NS"]=>
string(15) "Nouvelle-Ãcosse"
["NU"]=>
string(7) "Nunavut"
["ON"]=>
string(7) "Ontario"
["QC"]=>
string(6) "Québec"
["SK"]=>
string(12) "Saskatchewan"
["NL"]=>
string(23) "Terre-Neuve-et-Labrador"
["YT"]=>
string(19) "Territoire du Yukon&q
[PHP-BUG] Bug #61464 [NEW]: Test bug, please ignore
From: fa Operating system: any PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:Test bug, please ignore Description: Test bug, please ignore, and don't close it either. Test script: --- Test bug, please ignore, and don't close it either. Expected result: Test bug, please ignore, and don't close it either. Actual result: -- Test bug, please ignore, and don't close it either. -- Edit bug report at https://bugs.php.net/bug.php?id=61464&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61464&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61464&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61464&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61464&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61464&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61464&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61464&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61464&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61464&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61464&r=support Expected behavior: https://bugs.php.net/fix.php?id=61464&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61464&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61464&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61464&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61464&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61464&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61464&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61464&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61464&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61464&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61464&r=mysqlcfg
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at https://bugs.php.net/bug.php?id=51983&edit=1
ID: 51983
Comment by: f...@php.net
Reported by:konstantin at symbi dot org
Summary:[fpm sapi] pm.status_path not working when
cgi.fix_pathinfo=1
Status: Analyzed
Type: Bug
Package:FPM related
Operating System: Any
PHP Version:5.3SVN-2010-06-03 (snap)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
> Do the issues with apache_mod_fastcgi still exist? I remember I've tested it
> with my patch and it worked well, maybe you've missed some of its settings?
Using a global mod_fastcgi configuration (where everything is sent to FPM)
returns full compliant fastcgi envars which are compatible
with the "rfc3875" mode.
Using a specific mod_fastcgi configuration (AddHandler, AddAction and Alias)
returns buggy fastcgi envars which are compatible with the
"apache_mod_fastcgi" mode.
> Personally I don't like introducing such "magic" settings which are unclear
> on
> what they do. It reminds me of that crappy "broken-scriptfilename" and "fix-
> root-scriptname" lighttpd fastcgi settings. I indeed prefer the nginx way
where
> every fastcgi variable is configured explicitly.
I hear you. I don't really mind since the "magic" settings are documented and
explain what they do. A simple explication "use
apache_mod_fastcgi is your are using mod_fastcgi using ScriptAlias,
apache_mod_proxy_fcgi if your using mod_proxy_fcgi, compliant
otherwise. If you encouters problems, you can back to backward_compatibility".
And then a more specific explication
"apache_mod_fastcgi: The SCRIPT_FILENAME is deduced using DOCUMENT_ROOT +
PATH_INFO. If fix_pathinfo is set, then a reverse search is
made on the string to find out the SCRIPT_FILENAME part and the PATH_INFO part
by testing (using stat()3) the SCRIPT_FILENAME to ensure
it exists on disk."
"apache_mod_proxy_fcgi: the SCRIPT_FILENAME is deduced using DOCUMENT_ROOT +
(PATH_INFO || SCRIPT_NAME). Auto detection is used wether
to choose PATH_INFO or SCRIPT_NAME (it depends on the proxy-fcgi-pathinfo
settings). If fix_pathinfo is set, the same treatment is done
than it's done for apache_mod_fastcgi"
"rfc3875: SCRIPT_FILENAME is deduced using DOCUMENT_ROOT + SCRIPT_NAME. No
other
actions are taken as the PATH_INFO stuff is done by
the web server"
"backward_compatibility: old code untouched. Will maybe be removed in later
major release"
> In general it's OK, but I world prefer more obvious settings with names
telling
> about real fastcgi parameters. It's the matter of taste of course.
What do you have in mind ?
Another possibility would be to set the transormation rules inside of fpm
configuration with something like:
envvar[SCRIPT_FILENAME] = "%{DOCUMENT_ROOT}%{SCRIPT_NAME}"
envvar[SCRIPT_NAME] = "%{PATH_INFO}
and keep the usage of fix_pathinfo. If set, SCRIPT_FILENAME is searched for
real
file and PATH_INFO. Otherwise nothing is done.
In the comments, for each kind of configuration (mod_fastcgi, mod_proxy_fcgi,
nginx, lighttpd) the right settings are documented.
In the case, nothing is changed, try to make autodetection based on
SERVER_SOFTWARE maybe.
But, even if it's more detailed it's maybe too complex.
> Anyway, there are two things to take into account: known clients, and
> backward
> compatibility for any possible configuration. We need to remember that this
> is
> _remote_ fastcgi, and php-fpm may run on a different machine. For instance, I
> have seen a real life nginx configuration which looked like:
>
> set $remote_php_root /path/to/remote/php/root;
> SCRIPT_FILENAME $remote_root_php/$fastcgi_script_name;
>
> and DOCUMENT_ROOT was defined to the front web server root. It is senseless,
but
> it worked: SCRIPT_FILENAME was correct, and the php code did not use
> $_SERVER['DOCUMENT_ROOT'] at all.
In all the cases we can't match all the possible solutions, especially ones for
nginx as everything can be setup as desired.
Such a configuration is marginal, I think, and a little change won't kill
anyone
(I think).
> Also, these changes really should not go to php 5.4 (or go with "compat" mode
by
> default). There already have been a BC-breaking change with
>security.limit_extensions in minor update, I believe no one wants one more.
Agree. The code will be put in 5.3, 5.4 and 5.5 but the default settings will
be
set to "rfc3875" only for 5.5 (if it's not been
released yet).
Previous Comments:
[2013-05-13 22:57:03] konstantin at symbi
Bug #65088 [Com]: configure script (and compile) fails, perhaps due to BSD differences in SH
Edit report at https://bugs.php.net/bug.php?id=65088&edit=1 ID: 65088 Comment by: f...@php.net Reported by:stolen dot data dot net at gmail dot com Summary:configure script (and compile) fails, perhaps due to BSD differences in SH Status: Feedback Type: Bug Package:Compile Failure Operating System: OpenBSD 5.3 (possibly all BSDs) PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Addendum: This is my shell version: # echo $SH_VERSION @(#)PD KSH v5.2.14 99/07/13.2 Previous Comments: [2013-06-22 22:56:18] f...@php.net Just tried this on: OpenBSD puffy.lan 4.9 GENERIC#477 amd64 bash-4.1# /bin/sh # /bin/sh # cd /root/ # pwd /root # cd /usr/"local" # pwd /usr/local [2013-06-22 22:50:08] ras...@php.net So, a quick test on FreeBSD: $ /bin/sh $ cd /usr/"local" $ pwd /usr/local That doesn't work on your machine? We can't just remove the quotes there because it would break directory names with spaces and other shell-special characters in them. cd is a built-in in the shell and should support quoted literals. autoconf obviously relies on this being the case. Have you done something interesting to your /bin/sh on this box? [2013-06-22 22:36:21] ras...@php.net So basically autoconf generates a configure script that doesn't work on OpenBSD? That sounds a bit suspicious and I wonder why nobody else has reported it. Anything special about your environment? And can you reproduce just with just running the ./configure script with no args that comes with the php-5.5.0 tarball? I just tested it again on FreeBSD 9.0 and it worked flawlessly, so it is not a generic BSD issue. It is either OpenBSD-specific or specific to your environment. [2013-06-22 15:39:44] stolen dot data dot net at gmail dot com No, rebuilding configure changed nothing. Already gave it a try. [2013-06-22 03:23:54] ras...@php.net Seems fine on freebsd. If you re-generate the configure script, does it work? rm configure && ./buildconf --force The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65088 -- Edit this bug report at https://bugs.php.net/bug.php?id=65088&edit=1
Bug #61045 [PATCH]: fpm don't send error log to fastcgi clients(nginx)
Edit report at https://bugs.php.net/bug.php?id=61045&edit=1 ID: 61045 Patch added by: f...@php.net Reported by:lxlight at gmail dot com Summary:fpm don't send error log to fastcgi clients(nginx) Status: Assigned Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.10 Assigned To:fat Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61045-5.3.patch Revision: 1336233182 URL: https://bugs.php.net/patch-display.php?bug=61045&patch=bug61045-5.3.patch&revision=1336233182 Previous Comments: [2012-05-05 01:00:40] arohter at gmail dot com This is a showstopper for us; we've had to revert back to 5.3.8 so that we can trace and debug our application in both production and development. [2012-04-23 19:29:19] silvio dot ventres at gmail dot com The link to the patch got mangled: http://git.php.net/?p=php- src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9 http://goo.gl/11Whb [2012-04-23 19:27:40] silvio dot ventres at gmail dot com Tracked the change through git/svn. There is a zlog facility in php-fpm which provides output of operational errors, while fastcgi error logging facility is used to output application level errors. You can see how merging those into a single zlog which works on both seems like a good idea, but currently zlog does not even know what fpm is, having no access to fpm/fcgi variables or functions. So then, a patch "generalized" the behavior, and now all logs go through zlog. Unfortunately, zlog has no means of transporting the errors through fastcgi interface, and so fastcgi logging was lost. This is the patch in question: http://git.php.net/?p=php- src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9 The solution is either to revert this patch, or, which was probably the goal of the patch submitter, complete the zlog facility so it supports FastCGI natively. Since it doesn't seem like anyone fixed the zlog facility for half a year (since October 2011), it does seem simpler to revert the patch, or at least set it up as an option... [2012-04-04 12:58:34] tobi at portfolio dot hu The same here, I tried every php.ini and php-fpm.conf log setups, nothing works with Nginx 1.0.11 + PHP 5.3.10 FastCGI, even setting catch_workers_output = yes does not work. I dont know why this functionality was cutted out but our sites use logging via stderr + nginx, please solve it. [2012-03-29 09:36:44] kustodian at gmail dot com I wouldn't mind that change, but setting "catch_workers_output = yes" doesn't work for me with PHP 5.3.10 and Nginx 1.0.14 on Centos 6.2. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61045 -- Edit this bug report at https://bugs.php.net/bug.php?id=61045&edit=1
Bug #61045 [PATCH]: fpm don't send error log to fastcgi clients(nginx)
Edit report at https://bugs.php.net/bug.php?id=61045&edit=1 ID: 61045 Patch added by: f...@php.net Reported by:lxlight at gmail dot com Summary:fpm don't send error log to fastcgi clients(nginx) Status: Assigned Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.10 Assigned To:fat Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61045-5.4.patch Revision: 1336233195 URL: https://bugs.php.net/patch-display.php?bug=61045&patch=bug61045-5.4.patch&revision=1336233195 Previous Comments: [2012-05-05 15:53:02] f...@php.net The following patch has been added/updated: Patch Name: bug61045-5.3.patch Revision: 1336233182 URL: https://bugs.php.net/patch-display.php?bug=61045&patch=bug61045-5.3.patch&revision=1336233182 [2012-05-05 01:00:40] arohter at gmail dot com This is a showstopper for us; we've had to revert back to 5.3.8 so that we can trace and debug our application in both production and development. [2012-04-23 19:29:19] silvio dot ventres at gmail dot com The link to the patch got mangled: http://git.php.net/?p=php- src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9 http://goo.gl/11Whb [2012-04-23 19:27:40] silvio dot ventres at gmail dot com Tracked the change through git/svn. There is a zlog facility in php-fpm which provides output of operational errors, while fastcgi error logging facility is used to output application level errors. You can see how merging those into a single zlog which works on both seems like a good idea, but currently zlog does not even know what fpm is, having no access to fpm/fcgi variables or functions. So then, a patch "generalized" the behavior, and now all logs go through zlog. Unfortunately, zlog has no means of transporting the errors through fastcgi interface, and so fastcgi logging was lost. This is the patch in question: http://git.php.net/?p=php- src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9 The solution is either to revert this patch, or, which was probably the goal of the patch submitter, complete the zlog facility so it supports FastCGI natively. Since it doesn't seem like anyone fixed the zlog facility for half a year (since October 2011), it does seem simpler to revert the patch, or at least set it up as an option... [2012-04-04 12:58:34] tobi at portfolio dot hu The same here, I tried every php.ini and php-fpm.conf log setups, nothing works with Nginx 1.0.11 + PHP 5.3.10 FastCGI, even setting catch_workers_output = yes does not work. I dont know why this functionality was cutted out but our sites use logging via stderr + nginx, please solve it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61045 -- Edit this bug report at https://bugs.php.net/bug.php?id=61045&edit=1
Bug #62033 [PATCH]: php-fpm exits with status 0 on some failures to start
Edit report at https://bugs.php.net/bug.php?id=62033&edit=1
ID: 62033
Patch added by: f...@php.net
Reported by:js at justinsamuel dot com
Summary:php-fpm exits with status 0 on some failures to
start
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux (Ubuntu 12.04)
PHP Version:5.4.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62033.patch
Revision: 1337813451
URL:
https://bugs.php.net/patch-display.php?bug=62033&patch=bug62033.patch&revision=1337813451
Previous Comments:
[2012-05-23 22:10:59] f...@php.net
This is strange ...
can you please test the following patch and see if exit code is 42 on error ?
diff --git a/sapi/fpm/fpm/fpm_main.c b/sapi/fpm/fpm/fpm_main.c
index 95a7623..62c1b69 100644
--- a/sapi/fpm/fpm/fpm_main.c
+++ b/sapi/fpm/fpm/fpm_main.c
@@ -1803,7 +1803,8 @@ consult the installation file that came with this
distribution, or visit \n\
}
if (0 > fpm_init(argc, argv, fpm_config ? fpm_config :
CGIG(fpm_config),
fpm_prefix, fpm_pid, test_conf, php_allow_to_run_as_root)) {
- return FAILURE;
+// return FAILURE;
+ exit(42);
}
fpm_is_running = 1;
thx
++ Jerome
[2012-05-23 20:54:11] js at justinsamuel dot com
For simplicity here I'm going to focus on 5.3 instead of 5.4.
I've tried with the following:
* compiled from source (php.net tarballs) on Ubuntu 12.04
* compiled from source (php.net tarballs) on Debian 6
* Ubuntu 12.04's current php5-fpm package
* CentOS 6 with current php53u-fpm package from IUS
Here's the -tt info:
# /opt/test/php5.3/sbin/php-fpm --fpm-config /etc/php-test/fpm.conf -tt
[23-May-2012 13:07:26] NOTICE: [General]
[23-May-2012 13:07:26] NOTICE: pid = /var/run/php5.3-test.pid
[23-May-2012 13:07:26] NOTICE: error_log = /var/log/php5.3-test.log
[23-May-2012 13:07:26] NOTICE: syslog.ident = php-fpm
[23-May-2012 13:07:26] NOTICE: syslog.facility = 24
[23-May-2012 13:07:26] NOTICE: log_level = unknown value
[23-May-2012 13:07:26] NOTICE: emergency_restart_interval = 0s
[23-May-2012 13:07:26] NOTICE: emergency_restart_threshold = 0
[23-May-2012 13:07:26] NOTICE: process_control_timeout = 0s
[23-May-2012 13:07:26] NOTICE: process.max = 0
[23-May-2012 13:07:26] NOTICE: daemonize = yes
[23-May-2012 13:07:26] NOTICE: rlimit_files = 0
[23-May-2012 13:07:26] NOTICE: rlimit_core = 0
[23-May-2012 13:07:26] NOTICE: events.mechanism = epoll
[23-May-2012 13:07:26] NOTICE:
[23-May-2012 13:07:26] NOTICE: [example.com]
[23-May-2012 13:07:26] NOTICE: prefix = undefined
[23-May-2012 13:07:26] NOTICE: user = fakeuser
[23-May-2012 13:07:26] NOTICE: group = fakegroup
[23-May-2012 13:07:26] NOTICE: listen = /tmp/php5.3-test.sock
[23-May-2012 13:07:26] NOTICE: listen.backlog = 128
[23-May-2012 13:07:26] NOTICE: listen.owner = root
[23-May-2012 13:07:26] NOTICE: listen.group = root
[23-May-2012 13:07:26] NOTICE: listen.mode = 0700
[23-May-2012 13:07:26] NOTICE: listen.allowed_clients = undefined
[23-May-2012 13:07:26] NOTICE: pm = ondemand
[23-May-2012 13:07:26] NOTICE: pm.max_children = 1
[23-May-2012 13:07:26] NOTICE: pm.start_servers = 0
[23-May-2012 13:07:26] NOTICE: pm.min_spare_servers = 0
[23-May-2012 13:07:26] NOTICE: pm.max_spare_servers = 0
[23-May-2012 13:07:26] NOTICE: pm.process_idle_timeout = 10
[23-May-2012 13:07:26] NOTICE: pm.max_requests = 0
[23-May-2012 13:07:26] NOTICE: pm.status_path = undefined
[23-May-2012 13:07:26] NOTICE: ping.path = undefined
[23-May-2012 13:07:26] NOTICE: ping.response = undefined
[23-May-2012 13:07:26] NOTICE: access.log = undefined
[23-May-2012 13:07:26] NOTICE: access.format = undefined
[23-May-2012 13:07:26] NOTICE: slowlog = undefined
[23-May-2012 13:07:26] NOTICE: request_slowlog_timeout = 0s
[23-May-2012 13:07:26] NOTICE: request_terminate_timeout = 0s
[23-May-2012 13:07:26] NOTICE: rlimit_files = 0
[23-May-2012 13:07:26] NOTICE: rlimit_core = 0
[23-May-2012 13:07:26] NOTICE: chroot = undefined
[23-May-2012 13:07:26] NOTICE: chdir = undefined
[23-May-2012 13:07:26] NOTICE: catch_workers_output = no
[23-May-2012 13:07:26] NOTICE: security.limit_extensions = .php .phar
[23-May-2012 13:07:26] NOTICE:
[23-May-2012 13:07:26] NOTICE: configuration file /etc/php-test/fpm.conf test
is successful
Here's the version info for builds I've repeated this problem with. I haven't
had any builds not show show this problem yet.
## on Ubuntu 12.04, built from source
# /opt/test/php5.3/sbin/php-fpm --version
PHP 5.3.13 (fpm-fcgi) (built: May 23 2012 12:21:32)
Copyright (c) 1997-2009 The PHP Grou
Bug #62033 [PATCH]: php-fpm exits with status 0 on some failures to start
Edit report at https://bugs.php.net/bug.php?id=62033&edit=1
ID: 62033
Patch added by: f...@php.net
Reported by:js at justinsamuel dot com
Summary:php-fpm exits with status 0 on some failures to
start
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Linux (Ubuntu 12.04)
PHP Version:5.4.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62033-v2.patch
Revision: 1337935697
URL:
https://bugs.php.net/patch-display.php?bug=62033&patch=bug62033-v2.patch&revision=1337935697
Previous Comments:
[2012-05-24 00:08:03] js at justinsamuel dot com
I've tested this patch with the current PHP-5.3. The problem still persists.
A quick look with strace makes it seem that a child process is exiting with the
status that is expected from the patch (78) but its parent is not.
# rm -f /tmp/php-fpm.strace.*
# strace -o /tmp/php-fpm.strace -ff -f /opt/test/php5.3/sbin/php-fpm
--fpm-config /root/php-test/fpm.conf
[23-May-2012 18:54:57] ERROR: [pool example.com] cannot get uid for user
'fakeuser'
[23-May-2012 18:54:57] ERROR: FPM initialization failed
# echo $?
0
# ll /tmp/php-fpm.strace.*
-rw-r--r-- 1 root root 25282 May 23 18:54 /tmp/php-fpm.strace.996
-rw-r--r-- 1 root root 4125 May 23 18:54 /tmp/php-fpm.strace.997
# grep -B 2 exit /tmp/php-fpm.strace.*
/tmp/php-fpm.strace.996-clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f2e60ff19d0) = 997
/tmp/php-fpm.strace.996-munmap(0x7f2e60f6, 323584) = 0
/tmp/php-fpm.strace.996:exit_group(0) = ?
--
/tmp/php-fpm.strace.997-write(3, "[23-May-2012 18:54:57] ERROR: FP"..., 56) = 56
/tmp/php-fpm.strace.997-write(2, "[23-May-2012 18:54:57] ERROR: FP"..., 56) = 56
/tmp/php-fpm.strace.997:exit_group(78) = ?
Thanks,
Justin
----
[2012-05-23 22:51:57] f...@php.net
I've attached a real patch to this bug report.
Can you please test it ?
thx
++ Jerome
--------
[2012-05-23 22:50:51] f...@php.net
The following patch has been added/updated:
Patch Name: bug62033.patch
Revision: 1337813451
URL:
https://bugs.php.net/patch-display.php?bug=62033&patch=bug62033.patch&revision=1337813451
--------
[2012-05-23 22:10:59] f...@php.net
This is strange ...
can you please test the following patch and see if exit code is 42 on error ?
diff --git a/sapi/fpm/fpm/fpm_main.c b/sapi/fpm/fpm/fpm_main.c
index 95a7623..62c1b69 100644
--- a/sapi/fpm/fpm/fpm_main.c
+++ b/sapi/fpm/fpm/fpm_main.c
@@ -1803,7 +1803,8 @@ consult the installation file that came with this
distribution, or visit \n\
}
if (0 > fpm_init(argc, argv, fpm_config ? fpm_config :
CGIG(fpm_config),
fpm_prefix, fpm_pid, test_conf, php_allow_to_run_as_root)) {
- return FAILURE;
+// return FAILURE;
+ exit(42);
}
fpm_is_running = 1;
thx
++ Jerome
[2012-05-23 20:54:11] js at justinsamuel dot com
For simplicity here I'm going to focus on 5.3 instead of 5.4.
I've tried with the following:
* compiled from source (php.net tarballs) on Ubuntu 12.04
* compiled from source (php.net tarballs) on Debian 6
* Ubuntu 12.04's current php5-fpm package
* CentOS 6 with current php53u-fpm package from IUS
Here's the -tt info:
# /opt/test/php5.3/sbin/php-fpm --fpm-config /etc/php-test/fpm.conf -tt
[23-May-2012 13:07:26] NOTICE: [General]
[23-May-2012 13:07:26] NOTICE: pid = /var/run/php5.3-test.pid
[23-May-2012 13:07:26] NOTICE: error_log = /var/log/php5.3-test.log
[23-May-2012 13:07:26] NOTICE: syslog.ident = php-fpm
[23-May-2012 13:07:26] NOTICE: syslog.facility = 24
[23-May-2012 13:07:26] NOTICE: log_level = unknown value
[23-May-2012 13:07:26] NOTICE: emergency_restart_interval = 0s
[23-May-2012 13:07:26] NOTICE: emergency_restart_threshold = 0
[23-May-2012 13:07:26] NOTICE: process_control_timeout = 0s
[23-May-2012 13:07:26] NOTICE: process.max = 0
[23-May-2012 13:07:26] NOTICE: daemonize = yes
[23-May-2012 13:07:26] NOTICE: rlimit_files = 0
[23-May-2012 13:07:26] NOTICE: rlimit_core = 0
[23-May-2012 13:07:26] NOTICE: events.mechanism = epoll
[23-May-2012 13:07:26] NOTICE:
[23-May-2012 13:07:26] NOTICE: [example.com]
[23-May-2012 13:07:26] NOTICE: prefix = undefined
[23-May-2012 13:07:26] NOTICE: user = fakeuser
[23-May-2012 13:07:26] NOTICE: group = fakegroup
[23-May-2
[PHP-BUG] Bug #62153 [NEW]: when using unix sockets, multiples FPM instances can be launched without errors
From: fat Operating system: linux PHP version: 5.3Git-2012-05-25 (Git) Package: FPM related Bug Type: Bug Bug description:when using unix sockets, multiples FPM instances can be launched without errors Description: if a pool is listening to a local unix socket, the first instance to be launched create the socket and listen to it If a second instance is run, it erases the socket created by the first instance and creates its own. Resulting an inactive but runnung instance of FPM (the first one). The second instance should be able to detect if the unix socket already exists AND is already in used. -- Edit bug report at https://bugs.php.net/bug.php?id=62153&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62153&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62153&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62153&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62153&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62153&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62153&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62153&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62153&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62153&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62153&r=support Expected behavior: https://bugs.php.net/fix.php?id=62153&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62153&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62153&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62153&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62153&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62153&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62153&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62153&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62153&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62153&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62153&r=mysqlcfg
Req #62160 [Com]: Add Option: Low-Priority Pool
Edit report at https://bugs.php.net/bug.php?id=62160&edit=1 ID: 62160 Comment by: f...@php.net Reported by:geeky at geeky dot de Summary:Add Option: Low-Priority Pool Status: Analyzed Type: Feature/Change Request Package:FPM related Operating System: Debian 6.0 PHP Version:5.4.4RC1 Assigned To:fat Block user comment: N Private report: N New Comment: FPM is not design to manage priority between its processes. It just stop/start/restart/watch them. One thing which can be done is to play with nice(2) or setpriority(2). We can add a priority=[-19,20] parameter in the configuration file for each pool and the corresponding priority will be set when processes will be created. Is that something that can fit your needs ? thx for the answer. ++ fat Previous Comments: [2012-05-25 17:26:54] geeky at geeky dot de Description: It would be nice if a pool could be set to "low priority pool" (or even set a priority). Example: a website consisting of two parts: (1) frontend: responsive-time is essential here (2) background-synchronisation: should not slow down frontend, response-time is not important. In this case the background-pool should only use minimal/unused cpu-time in order to keep the frontend-pool at full speed. -- Edit this bug report at https://bugs.php.net/bug.php?id=62160&edit=1
Bug #61218 [Com]: FPM drops connection while receiving some binary values in FastCGI requests
Edit report at https://bugs.php.net/bug.php?id=61218&edit=1 ID: 61218 Comment by: f...@php.net Reported by:bruzh2 at gmail dot com Summary:FPM drops connection while receiving some binary values in FastCGI requests Status: Closed Type: Bug Package:FPM related Operating System: Ubuntu 10.04.4 LTS x64 PHP Version:5.3.10 Assigned To:fat Block user comment: N Private report: N New Comment: Thanks for your patch. In fact, I pushed another patch which removes the call to fcgi_param_get_eff_len for fcgi parameters values. it's now only called for fcgi parameters names. The fcgi parameters names must be valid strings ended with '\0'. ++ fat Previous Comments: [2012-05-26 17:37:34] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=e7a7f533e32813b13255efa236b711f6d1f6325d Log: Fixed bug #61218 (the previous patch was not enough restritive on fcgi name string checks) [2012-05-26 17:37:33] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=773e85a788de7dc557201d4af2cb10250c049052 Log: Fixed bug #61218 (the previous patch was not enough restritive on fcgi name string checks) [2012-05-26 17:37:32] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=2f7bd57f930bcfdc97b7472fbe6a502cafdc5a59 Log: Fixed bug #61218 (the previous patch was not enough restritive on fcgi name string checks) [2012-05-26 17:29:25] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-05-26 17:29:11] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=78de6eb03d3a24691d9f535e2cbe768a9ba8bd48 Log: Fixed bug #61218 (FPM drops connection while receiving some binary values in FastCGI requests) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61218 -- Edit this bug report at https://bugs.php.net/bug.php?id=61218&edit=1
Bug #60891 [PATCH]: FPM status serving should be moved to the master process
Edit report at https://bugs.php.net/bug.php?id=60891&edit=1 ID: 60891 Patch added by: f...@php.net Reported by:erno dot kovacs at freemail dot hu Summary:FPM status serving should be moved to the master process Status: Analyzed Type: Bug Package:FPM related Operating System: Any PHP Version:5.3.9 Assigned To:fat Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60891-v1.patch Revision: 1338246496 URL: https://bugs.php.net/patch-display.php?bug=60891&patch=bug60891-v1.patch&revision=1338246496 Previous Comments: [2012-01-26 14:57:22] ml at fatbsd dot com for security reason and by design it's not possible to make the master process to listen to those requests. The only possibility is to fork another process only to handle this. And this is quite a a big change. It's on my todo list but no ETA yet. ++ fat [2012-01-26 13:08:01] erno dot kovacs at freemail dot hu Description: When the server is overloaded, you cant query the FPM status page, however it should be its primary goal: being able to check whats going on. This way this cool feature is pointless. Test script: --- fpm conf: pm = dynamic pm.max_children = 1 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 1 test script: And while the only worker process is sleeping, send a query to the status page. It wont be served. Expected result: Status page. Actual result: -- Hanging -- Edit this bug report at https://bugs.php.net/bug.php?id=60891&edit=1
Bug #62205 [Com]: php-fpm segfaults (null passed to strstr)
Edit report at https://bugs.php.net/bug.php?id=62205&edit=1 ID: 62205 Comment by: f...@php.net Reported by:alp at rsu dot ru Summary:php-fpm segfaults (null passed to strstr) Status: Assigned Type: Bug Package:Unknown/Other Function Operating System: ubuntu linux 12.04 PHP Version:5.4Git-2012-06-01 (Git) Assigned To:fat Block user comment: N Private report: N New Comment: I'm on it. I've found this bug few days ago and I was waiting to finitsh something in the fpm_status code to fix this bug. I'll fix this now but I won't use the patch as there's something cleaner to check the presence of some parameters in the query string. i'll try to push this patch this morning. Previous Comments: [2012-06-01 08:46:56] larue...@php.net the patch looks good, but it is better assign this to fat, and ask for his reviewing :) thanks [2012-06-01 08:35:58] alp at rsu dot ru Description: In sapi/fpm/fpm/fpm_status.c NULL can be passed to strstr, which leads to php-fpm crash with: (gdb) bt #0 __strstr_sse42 (s1=0x0, s2=) at ../sysdeps/x86_64/multiarch/strstr.c:175 #1 0x00736d13 in fpm_status_handle_request () at /home/alp/build/php5-5.3.10/sapi/fpm/fpm/fpm_status.c:128 #2 0x0042b4ab in main (argc=11237155, argv=0x0) at /home/alp/build/php5-5.3.10/sapi/fpm/fpm/fpm_main.c:1809 The crash happens when monitoring software access php-fpm status page. -- Edit this bug report at https://bugs.php.net/bug.php?id=62205&edit=1
Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)
Edit report at https://bugs.php.net/bug.php?id=61045&edit=1 ID: 61045 Comment by: f...@php.net Reported by:lxlight at gmail dot com Summary:fpm don't send error log to fastcgi clients(nginx) Status: Closed Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.10 Assigned To:fat Block user comment: N Private report: N New Comment: yes this fix will go live in the next 5.3 and 5.4 release. Previous Comments: [2012-06-15 05:25:40] hb at peytz dot dk Any news about when this will see a release? Maybe 5.3.15 ? 5.4.5? [2012-05-22 17:46:33] arohter at gmail dot com Does this mean the fix will go live in the official 5.3.14 release? [2012-05-22 16:54:43] a...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=faca4e08b4dffbf00b1bc20fc5d4e310b3f99c13 Log: - Fixed bug #61045 (fpm don't send error log to fastcgi clients) [2012-05-22 07:05:31] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-05-22 06:47:44] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=dce259099df6505bb82b63700e4d14832b74e8c1 Log: - Fixed bug #61045 (fpm don't send error log to fastcgi clients) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61045 -- Edit this bug report at https://bugs.php.net/bug.php?id=61045&edit=1
#48102 [NEW]: run-tests.php and symlinked tests
From: f...@php.net Operating system: Linux PHP version: 6CVS-2009-04-28 (CVS) PHP Bug Type: Feature/Change Request Bug description: run-tests.php and symlinked tests Description: I was just trying out some tests written for 5.3 with HEAD, when I noticed the following: $ make test TESTS=ext/whatever Warning: fopen(): Filename cannot be empty in /root/src/php6/run-tests.php on line 1164 ERROR: Cannot open test file: make: [test] Error 1 (ignored) That means if there's a symlink with no endpoint, the whole testsuite can't run. It works fine if the symlinked file is just an empty (existing) file: BORK cannot read test [/tmp/foo] Yes, having tests only symlinked inside the source dir might be weird, so I filed this as feature request and not bug Reproduce code: --- $ touch /tmp/foo $ ln -s /tmp/foo /path/to/php-src/ext/whatever/tests/foo.phpt $ rm /tmp/foo $ make test TESTS=ext/whatever Expected result: $ make test TESTS=ext/whatever [...] BORK symlink endpoint /tmp/foo doesn't exist Actual result: -- $ make test TESTS=ext/whatever Warning: fopen(): Filename cannot be empty in /root/src/php6/run-tests.php on line 1164 ERROR: Cannot open test file: make: [test] Error 1 (ignored) -- Edit bug report at http://bugs.php.net/?id=48102&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48102&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48102&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48102&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48102&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48102&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48102&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48102&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48102&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48102&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48102&r=support Expected behavior: http://bugs.php.net/fix.php?id=48102&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48102&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48102&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48102&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48102&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48102&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48102&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48102&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48102&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48102&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48102&r=mysqlcfg
[PHP-BUG] Bug #51588 [NEW]: calling zend_parse_ini_string/file recursively core dump
From: fat
Operating system: any
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:calling zend_parse_ini_string/file recursively core dump
Description:
when zend_parse_ini_string or zend_parse_ini_file is called recursively, it
crashes. The lexical state variable is global, calling those function
recursively
overwrites previous version and crashes at liberation/destruction.
to prevent this behaviour, the following patch makes zend_parse_ini_string
or
zend_parse_ini_file returning an error when called recursively.
Test script:
---
void fpm_conf_ini_load_file(filename);
static void fpm_conf_ini_parser(zval *arg1, zval *arg2, zval *arg3,
int callback_type, void *arg TSRMLS_DC) {
if (!arg1) return;
if (callback_type != ZEND_INI_PARSER_ENTRY) return;
if (!strcmp(Z_STRVAL_P(arg1), "include")) {
fpm_conf_load_ini_file(Z_STRVAL_P(arg1));
}
}
void fpm_conf_ini_load_file(filename) {
zend_file_handle fh;
fh.handle.fp = VCWD_FOPEN(filename, "r");
fh.opened_path = NULL;
fh.free_filename = 0;
fh.filename = filename;
Z_TYPE(fh) = ZEND_HANDLE_FP;
zend_parse_ini_file(&fh, 1, ZEND_INI_SCANNER_RAW,
(zend_ini_parser_cb_t)fpm_conf_ini_parser, NULL TSRMLS_CC);
}
Expected result:
it doesn't crash, it works or returns an error
Actual result:
--
core dump
#0 _zend_mm_free_int (heap=0x8271c000, p=0x8271c000) at /LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2018
#1 0x1c23154a in _efree (ptr=0x7d3fe1f8) at /LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2351
#2 0x1c245b5b in zend_stack_destroy (stack=0x3c2c2804) at /LIBRE/dev/php-
5.3.2/Zend/zend_stack.c:104
#3 0x1c22bd1c in shutdown_ini_scanner () at zend_ini_scanner.l:201
#4 0x1c22b035 in zend_parse_ini_file (fh=0xcfbd3c70, unbuffered_errors=1
'\001', scanner_mode=0, ini_parser_cb=0x8271c000, arg=0x8271c000) at
/LIBRE/dev/php-5.3.2/Zend/zend_ini_parser.c:322
#5 0x1c2aefa8 in fpm_conf_load_ini_file (filename=0xcfbd602e
"/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:739
#6 0x1c2af002 in fpm_conf_load_ini_file (filename=0xcfbd602e
"/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:751
#7 0x1c2ad489 in fpm_init (argc=-2106474496, argv=0x8271c000,
config=0x8271c000
"\001", base=0x3c2bf81c) at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm.c:32
#8 0x1c2b14ff in main (argc=3, argv=0xcfbd5eac) at /LIBRE/dev/php-
5.3.2/sapi/fpm/fpm/fpm_main.c:1695
--
Edit bug report at http://bugs.php.net/bug.php?id=51588&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51588&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51588&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51588&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51588&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51588&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51588&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51588&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51588&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51588&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51588&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51588&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51588&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51588&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51588&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51588&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51588&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51588&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51588&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51588&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51588&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51588&r=mysqlcfg
Bug #51588 [PATCH]: calling zend_parse_ini_string/file recursively core dump
Edit report at http://bugs.php.net/bug.php?id=51588&edit=1
ID: 51588
Patch added by: f...@php.net
Reported by: f...@php.net
Summary: calling zend_parse_ini_string/file recursively core
dump
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: any
PHP Version: 5.3.2
New Comment:
The following patch has been added/updated:
Patch Name: zend_ini_parser.y.patch
Revision: 1271586553
URL:
http://bugs.php.net/patch-display.php?bug=51588&patch=zend_ini_parser.y.patch&revision=1271586553
Previous Comments:
[2010-04-18 12:28:33] f...@php.net
Description:
when zend_parse_ini_string or zend_parse_ini_file is called recursively,
it
crashes. The lexical state variable is global, calling those function
recursively
overwrites previous version and crashes at liberation/destruction.
to prevent this behaviour, the following patch makes
zend_parse_ini_string or
zend_parse_ini_file returning an error when called recursively.
Test script:
---
void fpm_conf_ini_load_file(filename);
static void fpm_conf_ini_parser(zval *arg1, zval *arg2, zval *arg3,
int callback_type, void *arg TSRMLS_DC) {
if (!arg1) return;
if (callback_type != ZEND_INI_PARSER_ENTRY) return;
if (!strcmp(Z_STRVAL_P(arg1), "include")) {
fpm_conf_load_ini_file(Z_STRVAL_P(arg1));
}
}
void fpm_conf_ini_load_file(filename) {
zend_file_handle fh;
fh.handle.fp = VCWD_FOPEN(filename, "r");
fh.opened_path = NULL;
fh.free_filename = 0;
fh.filename = filename;
Z_TYPE(fh) = ZEND_HANDLE_FP;
zend_parse_ini_file(&fh, 1, ZEND_INI_SCANNER_RAW,
(zend_ini_parser_cb_t)fpm_conf_ini_parser, NULL TSRMLS_CC);
}
Expected result:
it doesn't crash, it works or returns an error
Actual result:
--
core dump
#0 _zend_mm_free_int (heap=0x8271c000, p=0x8271c000) at
/LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2018
#1 0x1c23154a in _efree (ptr=0x7d3fe1f8) at /LIBRE/dev/php-
5.3.2/Zend/zend_alloc.c:2351
#2 0x1c245b5b in zend_stack_destroy (stack=0x3c2c2804) at
/LIBRE/dev/php-
5.3.2/Zend/zend_stack.c:104
#3 0x1c22bd1c in shutdown_ini_scanner () at zend_ini_scanner.l:201
#4 0x1c22b035 in zend_parse_ini_file (fh=0xcfbd3c70,
unbuffered_errors=1
'\001', scanner_mode=0, ini_parser_cb=0x8271c000, arg=0x8271c000) at
/LIBRE/dev/php-5.3.2/Zend/zend_ini_parser.c:322
#5 0x1c2aefa8 in fpm_conf_load_ini_file (filename=0xcfbd602e
"/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:739
#6 0x1c2af002 in fpm_conf_load_ini_file (filename=0xcfbd602e
"/usr/local/php-
5.3.2/etc/fpm.ini") at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm_conf.c:751
#7 0x1c2ad489 in fpm_init (argc=-2106474496, argv=0x8271c000,
config=0x8271c000
"\001", base=0x3c2bf81c) at /LIBRE/dev/php-5.3.2/sapi/fpm/fpm/fpm.c:32
#8 0x1c2b14ff in main (argc=3, argv=0xcfbd5eac) at /LIBRE/dev/php-
5.3.2/sapi/fpm/fpm/fpm_main.c:1695
--
Edit this bug report at http://bugs.php.net/bug.php?id=51588&edit=1
Bug #51587 [Com]: compile php 5.3.2 with php-fpm error
Edit report at http://bugs.php.net/bug.php?id=51587&edit=1 ID: 51587 Comment by: f...@php.net Reported by: amoiz dot shine at gmail dot com Summary: compile php 5.3.2 with php-fpm error Status: Open Type: Bug Package: FPM related Operating System: CentOS 5 i686 PHP Version: 5.3.2 New Comment: please provide more informations. See http://bugs.php.net/how-to-report.php and especially http://bugs.php.net/bugs- generating-backtrace.php ++ Jerome Previous Comments: [2010-04-18 10:47:29] amoiz dot shine at gmail dot com Description: i download the php source tarball from php.net. and check out lastest version of php-fpm from SVN. then,i run the ./configure --prefix=/usr/local/php --bindir=/usr/local/bin --sbindir=/usr/local/sbin --sysconfdir=/etc/sysconfig --enable-embed=shared --enable-fpm --enable-safe-mode --enable-sigchild --enable-magic-quotes --enable-fd-setsize=100 --enable-calendar --enable-dba=shared --enable-exif --enable-ftp --enable-gd-native-ttf --enable-intl --enable-mbstring --enable-embedded-mysqli --enable-pcntl --disable-phar --enable-shmop --enable-soap --enable-sockets --enable-wddx --enable-zip --enable-zend-multibyte --with-libxml-dir --with-libevent-dir=/usr/local/libevent --with-fpm-user=php --with-fpm-group=php --with-config-file-path=/etc --with-exec-dir=/usr/local/bin --with-openssl --with-kerberos --with-pcre-regex --with-zlib --with-bz2 --with-curl --with-gd --with-mhash --with-imap --with-imap-ssl --with-ldap --with-ldap-sasl --with-mcrypt --with-mysql=/usr/local/mysql --with-mysql-sock=/tmp/mysql.sock --with-mysqli=/usr/local/bin/mysql_config --with-pdo-mysql=/usr/local/bin/mysql_config --with-xmlrpc --with-pear it seems to be ok,and run make command.it looks like NO error appears,too but when i run the make install,it gives some information below: [r...@powerpc php-5.3.2]# make install /bin/sh /root/php-5.3.2/libtool --silent --preserve-dup-deps --mode=install cp ext/dba/dba.la /root/php-5.3.2/modules Installing PHP SAPI module: fpm Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ Installing shared extensions: /usr/local/php/lib/php/extensions/no-debug-non-zts-20090626/ Installing PHP FPM binary:/usr/local/sbin/ Installing PHP FPM config:/etc/sysconfig/ Installing PHP FPM man page: /usr/local/php/man/man1/ Installing build environment: /usr/local/php/lib/php/build/ Installing header files: /usr/local/php/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 I Do Not know what caused it.. and i run the php-fpm ,it returns "Segmentation fault" Test script: --- See my configure string Expected result: Install Success and php-fpm works OK. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/bug.php?id=51587&edit=1
[PHP-BUG] Req #51595 [NEW]: passing ini settings via FASTCGI parameters
From: fat Operating system: any PHP version: 5.3SVN-2010-04-19 (SVN) Package: FPM related Bug Type: Feature/Change Request Bug description:passing ini settings via FASTCGI parameters Description: It would be cool to be able to define ini settings directly in the web server (nginx, lighthttpd, apache) the same way it's possible for the apache sapi (php_value, php_admin_value, ...) Test script: --- no test Expected result: nginx conf sample: fastcgi_param PHP_VALUE sessions.save_path=/home/www/sessions/ fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs Actual result: -- it doesn not exist -- Edit bug report at http://bugs.php.net/bug.php?id=51595&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51595&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51595&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51595&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51595&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51595&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51595&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51595&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51595&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51595&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51595&r=support Expected behavior: http://bugs.php.net/fix.php?id=51595&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51595&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51595&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51595&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51595&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51595&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51595&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51595&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51595&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51595&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51595&r=mysqlcfg
Req #51595 [Com]: passing ini settings via FASTCGI parameters
Edit report at http://bugs.php.net/bug.php?id=51595&edit=1 ID: 51595 Comment by: f...@php.net Reported by: f...@php.net Summary: passing ini settings via FASTCGI parameters Status: Open Type: Feature/Change Request Package: FPM related Operating System: any PHP Version: trunk New Comment: thanks for the correction Previous Comments: [2010-04-19 09:03:26] paj...@php.net Change version, 5.3 does not have fpm. [2010-04-19 01:56:59] f...@php.net Description: It would be cool to be able to define ini settings directly in the web server (nginx, lighthttpd, apache) the same way it's possible for the apache sapi (php_value, php_admin_value, ...) Test script: --- no test Expected result: nginx conf sample: fastcgi_param PHP_VALUE sessions.save_path=/home/www/sessions/ fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs Actual result: -- it doesn not exist -- Edit this bug report at http://bugs.php.net/bug.php?id=51595&edit=1
Bug #51736 [PATCH]: configuration parsing problem
Edit report at http://bugs.php.net/bug.php?id=51736&edit=1 ID: 51736 Patch added by: f...@php.net Reported by: mauro dot stettler at gmail dot com Summary: configuration parsing problem Status: Assigned Type: Bug Package: FPM related Operating System: suse linux (SLES11) PHP Version: Irrelevant Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: bug51736.patch Revision: 1273306941 URL: http://bugs.php.net/patch-display.php?bug=51736&patch=bug51736.patch&revision=1273306941 Previous Comments: [2010-05-04 09:00:56] mauro dot stettler at gmail dot com Description: i tested the revision 298795 of php-fpm and i experienced that the config value of min_spare_servers always gets copied into the config value of max_spare_servers, which then means that start_servers will also have to be equal to this, Test script: --- ; Sets the number of server processes created on startup. ; Used only with 'dynamic' pm.style ; default : min_spare + (max_spare - min_spare) / 2 ; pm.start_servers = 50 ; Sets the desired minimum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.min_spare_servers = 10 ; Sets the desired maximum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.max_spare_servers = 100 Expected result: should be able to start php-fpm server Actual result: -- the result is that on start of php-fpm server, the fpm gives out a config error if you use the above pasted configuration -- Edit this bug report at http://bugs.php.net/bug.php?id=51736&edit=1
Bug #51736 [Com]: configuration parsing problem
Edit report at http://bugs.php.net/bug.php?id=51736&edit=1 ID: 51736 Comment by: f...@php.net Reported by: mauro dot stettler at gmail dot com Summary: configuration parsing problem Status: Assigned Type: Bug Package: FPM related Operating System: suse linux (SLES11) PHP Version: Irrelevant Assigned To: fat New Comment: Can you please try the attached patch to confirm it fixes the bug ? Thx ++ Jerome Previous Comments: [2010-05-08 10:22:21] f...@php.net The following patch has been added/updated: Patch Name: bug51736.patch Revision: 1273306941 URL: http://bugs.php.net/patch-display.php?bug=51736&patch=bug51736.patch&revision=1273306941 [2010-05-04 09:00:56] mauro dot stettler at gmail dot com Description: i tested the revision 298795 of php-fpm and i experienced that the config value of min_spare_servers always gets copied into the config value of max_spare_servers, which then means that start_servers will also have to be equal to this, Test script: --- ; Sets the number of server processes created on startup. ; Used only with 'dynamic' pm.style ; default : min_spare + (max_spare - min_spare) / 2 ; pm.start_servers = 50 ; Sets the desired minimum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.min_spare_servers = 10 ; Sets the desired maximum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.max_spare_servers = 100 Expected result: should be able to start php-fpm server Actual result: -- the result is that on start of php-fpm server, the fpm gives out a config error if you use the above pasted configuration -- Edit this bug report at http://bugs.php.net/bug.php?id=51736&edit=1
Bug #51736 [Com]: configuration parsing problem
Edit report at http://bugs.php.net/bug.php?id=51736&edit=1 ID: 51736 Comment by: f...@php.net Reported by: mauro dot stettler at gmail dot com Summary: configuration parsing problem Status: Assigned Type: Bug Package: FPM related Operating System: suse linux (SLES11) PHP Version: Irrelevant Assigned To: fat New Comment: This bug has been corrected on revision 299141. Previous Comments: [2010-05-08 10:52:34] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=299141 Log: Fix #51736, wrong checks on dynamic parameters [2010-05-08 10:23:25] f...@php.net Can you please try the attached patch to confirm it fixes the bug ? Thx ++ Jerome [2010-05-08 10:22:21] f...@php.net The following patch has been added/updated: Patch Name: bug51736.patch Revision: 1273306941 URL: http://bugs.php.net/patch-display.php?bug=51736&patch=bug51736.patch&revision=1273306941 [2010-05-04 09:00:56] mauro dot stettler at gmail dot com Description: i tested the revision 298795 of php-fpm and i experienced that the config value of min_spare_servers always gets copied into the config value of max_spare_servers, which then means that start_servers will also have to be equal to this, Test script: --- ; Sets the number of server processes created on startup. ; Used only with 'dynamic' pm.style ; default : min_spare + (max_spare - min_spare) / 2 ; pm.start_servers = 50 ; Sets the desired minimum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.min_spare_servers = 10 ; Sets the desired maximum number of idle server processes. ; Used only with 'dynamic' pm.style ; It's mandatory when pm is set to dynamic ; pm.max_spare_servers = 100 Expected result: should be able to start php-fpm server Actual result: -- the result is that on start of php-fpm server, the fpm gives out a config error if you use the above pasted configuration -- Edit this bug report at http://bugs.php.net/bug.php?id=51736&edit=1
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: f...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: Have you tried your patch with other webservers than nginx and lighttpd ? Previous Comments: [2010-06-04 06:32:12] sergo_s at bk dot ru I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else we do not know the script_filename. And, of course, it fixes the problem with pm.status_path I started with. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: f...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: I'm asking about Apache, to be certain not to ban some webservers from using FPM. According to http://www.fastcgi.com/drupal/node/3, we have to make sure that FPM is compliant with all of the following webservers: Apache Microsoft IIS Microsoft IIS (second generation) SunOne Lighttpd Premium thttpd http MyServer Pi3Web WebSTAR (Mac OS) Nginx Cherokee Previous Comments: [2010-06-04 08:52:49] konstantin at symbi dot org 99% of fpm installations are with nginx or lighty, using fpm sapi with non-FSM webservers is at least very strange. But I have just checked it with Apache+mod_fastcgi in a simplest configuration: DocumentRoot "/var/www" FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock Options FollowSymLinks +ExecCGI AllowOverride All Order Allow,Deny Allow from all and it works OK. The patch contains comments in the top of the new init_request_info() implementation. It describes why fastcgi parameters are mapped to the script filename in this way, and it was chosen after examining CGI specs, typical fpm configurations, and common sense. BTW, those webservers like old IIS versions with buggy cgi implementations which required that awkward way of guessing what they meant, for which the original implementation of init_request_info() was designed, do not support remote FastCGI at all. [2010-06-04 08:25:19] f...@php.net Have you tried your patch with other webservers than nginx and lighttpd ? [2010-06-04 06:32:12] sergo_s at bk dot ru I met problem "No input file specified" in the configuration of lighttpd 1.4.26 + php-5.3.2 + fastcgi/php-fpm when requesting addresses like index.php/myMethod/ (kohanaframework based site). I found that $_SERVER[PATH_INFO] is NULL. (More about my problem in this post: http://phpclub.ru/talk/showthread.php?s=&postid=902382 (russian)) This patch solved the problem. Thanks. [2010-06-03 04:42:33] konstantin at symbi dot org Description: FPM status does not work when cgi.fix_pathinfo = 1, with the default nginx configuration for php (default fastcgi_params + SCRIPT_FILENAME added). The problems is that in fpm_main.c, here: if (!strcasecmp(SG(request_info).request_method, "GET") && fpm_status_handle_status(SG(request_info).request_uri, ... SG(request_info).request_uri is sometimes NULL depending on the trickiest things which happen when cgi.fix_pathinfo = 1. I have examined the code of init_request_info() which runs when cgi.fix_pathinfo = 1, and I found out that this part of code is legacy part from the CGI SAPI, it is was designed to fix problems with a lots of broken CGI implementations. It was reasonable for CGI to get the things working independent on speed, but the 'bruteforce' approach used is not too good for FPM SAPI which is commonly used on high-bandwidth sites. More, PHP introduces non-standard "SCRIPT_FILENAME" fastcgi env; it is not hard to add it to configuration of flexible servers like nginx (by using "fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name" in its configuration), but it can cause problems with such servers as lighttpd where all the fastcgi parameters are hardcoded (I've seen people on forums complaining thay get 'no input file' with nginx+fpm and they found no way to fix it). So, I have found the fix_pathinfo part is written in a hard to understand and difficult to fix way, and that is is really not required for FPM SAPI, and that it slows it down. System administrators who configure FSM webservers and use FPM sapi are usually experianced and for them it would be preferable to have strict and simple logic rather then some magic which can potentially slow things down a lot. So i have rewritten init_request_info(), the the suggested patch is attached. It logic of detection script_filename is much simpler: if SCRIPT_FILENAME is defined, use it, else if both DOCUMENT_ROOT and SCRIPT_NAME are defined, concat them and use (should fix all the problems with lighty etc); else if PATH_TRALSLATED is defined, use it as script_filename; else w
Bug #51983 [Com]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983&edit=1 ID: 51983 Comment by: f...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: I mentioned all the web servers to make sure we agree on doing this. I totaly agree on making this change. This pathinfo thing sucks for real. Previous Comments: [2010-06-09 15:59:48] tony2...@php.net Jerome, I agree that we should drop this fix_pathinfo stuff - it makes no sense to adopt all the freaky things from CGI API. The patch requires some extensive testing, though, that's clear. But I don't think we should keep in mind of all the web-servers you mentioned. Apache, nginx & lightty are my biggest concern, others can be safely dropped (or assumed working). You can forget about IIS anyway, FPM doesn't support Windows. [2010-06-04 09:07:10] konstantin at symbi dot org And of course I never say we should do anything with the CGI/FCGI sapi. I am sure its implementation must not be chanhed 'cause it was tested with many webservers during years. I am speaking only about FPM sapi which is much more specific. [2010-06-04 09:04:54] konstantin at symbi dot org FPM sapi implements remote fastcgi only (also known as "external FastCGI"). So it is limited to web servers which support it. I have tested Nginx, Lighttpd, and Apache mod_fastcgi. For other webservers listed, are there ones which of them support remote fastcgi? At least I am sure that IIS does not (even with its latest fastcgi implementations, I've asked this question on IIS FastCGI forums). As far as I know, thttpd does not, too. ---- [2010-06-04 08:59:23] f...@php.net I'm asking about Apache, to be certain not to ban some webservers from using FPM. According to http://www.fastcgi.com/drupal/node/3, we have to make sure that FPM is compliant with all of the following webservers: Apache Microsoft IIS Microsoft IIS (second generation) SunOne Lighttpd Premium thttpd http MyServer Pi3Web WebSTAR (Mac OS) Nginx Cherokee [2010-06-04 08:52:49] konstantin at symbi dot org 99% of fpm installations are with nginx or lighty, using fpm sapi with non-FSM webservers is at least very strange. But I have just checked it with Apache+mod_fastcgi in a simplest configuration: DocumentRoot "/var/www" FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock Options FollowSymLinks +ExecCGI AllowOverride All Order Allow,Deny Allow from all and it works OK. The patch contains comments in the top of the new init_request_info() implementation. It describes why fastcgi parameters are mapped to the script filename in this way, and it was chosen after examining CGI specs, typical fpm configurations, and common sense. BTW, those webservers like old IIS versions with buggy cgi implementations which required that awkward way of guessing what they meant, for which the original implementation of init_request_info() was designed, do not support remote FastCGI at all. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51983 -- Edit this bug report at http://bugs.php.net/bug.php?id=51983&edit=1
Bug #52045 [PATCH]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Patch added by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 Previous Comments: [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Bug #52045 [Com]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Comment by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: Can you please try the attached patch on trunk ? It must be also working on branche/PHP_5_3. ++ jerome Previous Comments: [2010-06-11 14:10:14] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 Previous Comments: [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome Previous Comments: ---- [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
[PHP-BUG] Bug #52067 [NEW]: chdir to a nonexisting directory when chrooting is buggy
From: fat Operating system: linux PHP version: 5.3SVN-2010-06-12 (SVN) Package: FPM related Bug Type: Bug Bug description:chdir to a nonexisting directory when chrooting is buggy Description: when setting chroot and chdir to a non existing directory into the chroot. FPM loops creating children which are dying because they can't chdir. Jun 12 19:46:10.884803 [NOTICE] [pool www] child 27114 started Jun 12 19:46:10.884930 [WARNING] [pool www] child 27114 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.885001 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884025 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.885072 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884153 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.886642 [NOTICE] [pool www] child 27115 started Jun 12 19:46:10.886768 [WARNING] [pool www] child 27115 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.886842 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885852 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.886914 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885982 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.888469 [NOTICE] [pool www] child 27116 started Jun 12 19:46:10.888596 [WARNING] [pool www] child 27116 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.888671 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887691 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.888744 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887820 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.890295 [NOTICE] [pool www] child 27117 started Jun 12 19:46:10.890422 [WARNING] [pool www] child 27117 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.890491 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889524 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.890563 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889651 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.893124 [NOTICE] [pool www] child 27119 started Jun 12 19:46:10.893256 [WARNING] [pool www] child 27119 exited with code 255 after 0.000155 seconds from start Jun 12 19:46:10.893329 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892335 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.893401 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892467 [ERROR] [pool www] child failed to initialize", pipe is closed Test script: --- chroot=/usr/local/nginx/html chdir=/usr/local/nginx/html -- Edit bug report at http://bugs.php.net/bug.php?id=52067&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52067&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52067&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52067&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52067&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52067&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52067&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52067&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52067&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52067&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52067&r=support Expected behavior: http://bugs.php.net/fix.php?id=52067&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52067&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52067&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52067&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52067&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52067&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52067&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52067&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52067&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52067&r=nozend MySQL Configuration Error: http:
Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 Previous Comments: [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome -------- [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. Previous Comments: [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. ---- [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome ---- [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 Previous Comments: [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. ---- [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome ---- [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: my mistakes. The v2 patch was buggy. Use v3 instead. Previous Comments: [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. ---- [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #51973 [Com]: a way to restart single pools, enable/disable modules per pool
Edit report at http://bugs.php.net/bug.php?id=51973&edit=1 ID: 51973 Comment by: f...@php.net Reported by: slogster at gmail dot com Summary: a way to restart single pools, enable/disable modules per pool Status: Assigned Type:Feature/Change Request Package: FPM related PHP Version: 5.3SVN-2010-06-02 (SVN) Assigned To: fat New Comment: For enabeling extensions you can use the php_admin_value setting for each pool: php_admin_value[extension] = extension.so Previous Comments: [2010-06-02 13:01:49] slogster at gmail dot com Description: Hi, I would like to be able do enable/disable modules per pool and would also like to be able to restart single pool when I change its config. Thanks -- Edit this bug report at http://bugs.php.net/bug.php?id=51973&edit=1
Bug #52086 [PATCH]: No new line at the end of a included pool file crahes the PHP FPM daemon
Edit report at http://bugs.php.net/bug.php?id=52086&edit=1 ID: 52086 Patch added by: f...@php.net Reported by: admin at saltwaterc dot net Summary: No new line at the end of a included pool file crahes the PHP FPM daemon Status: Assigned Type: Bug Package: FPM related Operating System: * PHP Version: 5.3.2 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-include.error.patch Revision: 1276614445 URL: http://bugs.php.net/patch-display.php?bug=52086&patch=fpm-include.error.patch&revision=1276614445 Previous Comments: [2010-06-15 14:49:38] admin at saltwaterc dot net Description: I have a script that automatically generates pool configurations based on input parameters and a template configuration. It didn't used to place a new line at the end of the generated configuration file which degenerated into a hard to debug error as the daemon crashes without any useful explanation. By adding a new line after the last configuration line (in my example, php_admin_value[upload_tmp_dir] = /home/example.com/tmp) everything works as expected. Test script: --- [example.com] user = example.com group = example.com listen = /var/run/php-fpm/example.com.sock pm = static pm.max_children = 2 pm.max_requests = 1 slowlog = /home/example.com/logs/fpm/slow.log chdir = /home/example.com/docroot php_admin_value[error_log] = /home/example.com/logs/fpm/error.log php_admin_value[open_basedir] = /home/example.com/docroot:/home/example.com/sessions:/home/example.com/tmp php_admin_value[session.save_path] = /home/example.com/sessions php_admin_value[upload_tmp_dir] = /home/example.com/tmp Expected result: Successful PHP FPM daemon start. Actual result: -- Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 15 12:35:12.090707 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/example.com.ini from /usr/local/zend/etc/php-fpm.conf at line 23 *** glibc detected *** /usr/local/zend/sbin/php-fpm: double free or corruption (fasttop): 0x1ac80380 *** + backtrace + memory map -- Edit this bug report at http://bugs.php.net/bug.php?id=52086&edit=1
Bug #50578 [Com]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Comment by: f...@php.net Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 Assigned To: cellog New Comment: fyi, the patch looks good to me. Previous Comments: [2010-06-14 09:12:38] gerwin at uber1337 dot nl Thanks for the patch Remi, it works just fine. It's an annoying bug though when you need to build rpm packages too and it would be nice to see it fixed. [2010-03-05 01:16:17] paj...@php.net Greg, can you valid and apply the patch please? Or simply valid it and I can apply it if it looks fine for you. [2010-03-05 01:04:57] paj...@php.net Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. [2010-03-04 22:30:55] Fedora at famillecollet dot com Same issue with 5.3.2 finale. [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50578 -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: Thanks for the reporting. I'll check that and answer you as soon as possible. Previous Comments: [2010-07-07 12:27:54] ef-lists at email dot de Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level -> slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar ---- [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. ---- [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 ---- [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. -------- [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Bug #52045 [Com]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Comment by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: Can you please test and report the result. thx ++ Jerome Previous Comments: [2010-06-15 12:02:57] paj...@php.net cd php-src patch < patchfile [2010-06-15 11:59:29] FractalizeR at yandex dot ru How do I correctly apply it? patch -d -i ? [2010-06-11 14:11:29] f...@php.net Can you please try the attached patch on trunk ? It must be also working on branche/PHP_5_3. ++ jerome [2010-06-11 14:10:14] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: some answers to your questions: 1- this is a bug. All comparaison should use strcasecmp so that users can type facilities and log level with the case they want. 2- you're right. php_syslog() should be used instead of syslog() 4- after testing and validating, yes of course. I need to take time reviewing all this. Thx again ! Previous Comments: [2010-07-07 13:17:07] f...@php.net Thanks for the reporting. I'll check that and answer you as soon as possible. [2010-07-07 12:27:54] ef-lists at email dot de Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level -> slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar -------- [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. -------- [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 -------- [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #51118 [PATCH]: Allow multiple simultaneous syslog connections
Edit report at http://bugs.php.net/bug.php?id=51118&edit=1
ID: 51118
Patch added by: f...@php.net
Reported by: sylvain at abstraction dot fr
Summary: Allow multiple simultaneous syslog connections
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: all
PHP Version: 5.2.12
New Comment:
The following patch has been added/updated:
Patch Name: php_syslog_multiple_context.patch
Revision: 1279855421
URL:
http://bugs.php.net/patch-display.php?bug=51118&patch=php_syslog_multiple_context.patch&revision=1279855421
Previous Comments:
[2010-02-22 18:57:36] sylvain at abstraction dot fr
Description:
the openlog function does not return a resource like would do the fopen
or any database connection function.
That implementation limits to 1 the simultaneous number of connections
possible to syslog and this is problematic when we aim to use syslog
with different log locals.
Expected result:
$syslog_local0 = openlog('foo', LOG_NDELAY, LOG_LOCAL0);
syslog($syslog_local0, LOG_WARNING, "blah");
$syslog_local1 = openlog('bar', LOG_NDELAY, LOG_LOCAL1);
syslog($syslog_local1, LOG_WARNING, "blah blah");
closelog($syslog_local0);
closelog($syslog_local1);
--
Edit this bug report at http://bugs.php.net/bug.php?id=51118&edit=1
Req #51118 [Com]: Allow multiple simultaneous syslog connections
Edit report at http://bugs.php.net/bug.php?id=51118&edit=1
ID: 51118
Comment by: f...@php.net
Reported by: sylvain at abstraction dot fr
Summary: Allow multiple simultaneous syslog connections
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: all
PHP Version: 5.2.12
New Comment:
I just attached a patch which should do the trick. I don't know if it'll
be
accepted by the dev team who handle this part of PHP.
openlog() returns a ressource instead of a bool.
closelog() and syslog() have now a last and optional parameter: a
context
ressource.
Everything which was working before, should still work. The only change
is the
return value of openlog() which should be strictely compared
(openlog(...) !==
true).
here is a sample test script:
Previous Comments:
[2010-07-23 05:23:41] f...@php.net
The following patch has been added/updated:
Patch Name: php_syslog_multiple_context.patch
Revision: 1279855421
URL:
http://bugs.php.net/patch-display.php?bug=51118&patch=php_syslog_multiple_context.patch&revision=1279855421
[2010-02-22 18:57:36] sylvain at abstraction dot fr
Description:
the openlog function does not return a resource like would do the fopen
or any database connection function.
That implementation limits to 1 the simultaneous number of connections
possible to syslog and this is problematic when we aim to use syslog
with different log locals.
Expected result:
$syslog_local0 = openlog('foo', LOG_NDELAY, LOG_LOCAL0);
syslog($syslog_local0, LOG_WARNING, "blah");
$syslog_local1 = openlog('bar', LOG_NDELAY, LOG_LOCAL1);
syslog($syslog_local1, LOG_WARNING, "blah blah");
closelog($syslog_local0);
closelog($syslog_local1);
--
Edit this bug report at http://bugs.php.net/bug.php?id=51118&edit=1
Bug #52045 [PATCH]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Patch added by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1279885008 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1279885008 Previous Comments: [2010-07-22 23:18:16] f...@php.net Can you please test and report the result. thx ++ Jerome [2010-06-15 12:02:57] paj...@php.net cd php-src patch < patchfile [2010-06-15 11:59:29] FractalizeR at yandex dot ru How do I correctly apply it? patch -d -i ? [2010-06-11 14:11:29] f...@php.net Can you please try the attached patch on trunk ? It must be also working on branche/PHP_5_3. ++ jerome [2010-06-11 14:10:14] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52045 -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Bug #52407 [PATCH]: FPM module compilation fails on ARM architecture
Edit report at http://bugs.php.net/bug.php?id=52407&edit=1 ID: 52407 Patch added by: f...@php.net Reported by: eugenesan at gmail dot com Summary: FPM module compilation fails on ARM architecture Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.3 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm_atomic_h_fix.patch Revision: 1279974965 URL: http://bugs.php.net/patch-display.php?bug=52407&patch=fpm_atomic_h_fix.patch&revision=1279974965 Previous Comments: [2010-07-24 10:38:29] eugenesan at gmail dot com I wasn't aware of atomic functionality in libgcc. In older version of FPM (before W-Mark Kubacki provided current solution), I was copying atomic functions available in libc :-) Also, W-Mark Kubacki tried to propose libatomic as generic solution for all platforms, but due to stability reasons solution was declined. Anyways, provided patch is only for urgent fixing of FPM on ARM in PHP 5.3.3. Later, I would expect more serious treatment of the issue by maintainers. [2010-07-24 02:00:20] geiss...@php.net As a matter of fact, why aren't the gcc atomic builtins used in all architectures if gcc > 4.1 is used? Otherwise it is going to be a pain to port the atomic code to many architectures. I've read that icc supports them too, but I don't know since when or anything else. For the Debian packages I'm going to do that, but I'd prefer to see the change happen here too (included a cleanup of the unused atomic_*_t types -- only atomic_t needs to be defined.) [2010-07-22 17:30:10] eugenesan at gmail dot com Patch passed heavy load test. [2010-07-22 17:21:20] der...@php.net Never mind, it's there now :-) [2010-07-22 17:20:49] der...@php.net I see no attachment. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52407 -- Edit this bug report at http://bugs.php.net/bug.php?id=52407&edit=1
Bug #52407 [Com]: FPM module compilation fails on ARM architecture
Edit report at http://bugs.php.net/bug.php?id=52407&edit=1 ID: 52407 Comment by: f...@php.net Reported by: eugenesan at gmail dot com Summary: FPM module compilation fails on ARM architecture Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.3 Assigned To: fat New Comment: Can you please test & validate this patch on ARM arch ? I've added an #error if ARM && gcc <= 4.2 Previous Comments: ---- [2010-07-24 14:36:05] f...@php.net The following patch has been added/updated: Patch Name: fpm_atomic_h_fix.patch Revision: 1279974965 URL: http://bugs.php.net/patch-display.php?bug=52407&patch=fpm_atomic_h_fix.patch&revision=1279974965 [2010-07-24 10:38:29] eugenesan at gmail dot com I wasn't aware of atomic functionality in libgcc. In older version of FPM (before W-Mark Kubacki provided current solution), I was copying atomic functions available in libc :-) Also, W-Mark Kubacki tried to propose libatomic as generic solution for all platforms, but due to stability reasons solution was declined. Anyways, provided patch is only for urgent fixing of FPM on ARM in PHP 5.3.3. Later, I would expect more serious treatment of the issue by maintainers. [2010-07-24 02:00:20] geiss...@php.net As a matter of fact, why aren't the gcc atomic builtins used in all architectures if gcc > 4.1 is used? Otherwise it is going to be a pain to port the atomic code to many architectures. I've read that icc supports them too, but I don't know since when or anything else. For the Debian packages I'm going to do that, but I'd prefer to see the change happen here too (included a cleanup of the unused atomic_*_t types -- only atomic_t needs to be defined.) [2010-07-22 17:30:10] eugenesan at gmail dot com Patch passed heavy load test. [2010-07-22 17:21:20] der...@php.net Never mind, it's there now :-) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52407 -- Edit this bug report at http://bugs.php.net/bug.php?id=52407&edit=1
[PHP-BUG] Bug #52498 [NEW]: when FPM is enable, php-cli is linked against libevent (it shouldn't)
From: fat Operating system: linux PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:when FPM is enable, php-cli is linked against libevent (it shouldn't) Description: r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 => /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... libevent-1.4.so.2 => /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb803) ... libevent is linked by sapi/cli/php when it shouldn't Test script: --- compile PHP with --enable-fpm Expected result: r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 => /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... ... Actual result: -- r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 => /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... libevent-1.4.so.2 => /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb803) ... -- Edit bug report at http://bugs.php.net/bug.php?id=52498&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52498&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52498&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52498&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52498&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52498&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52498&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52498&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52498&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52498&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52498&r=support Expected behavior: http://bugs.php.net/fix.php?id=52498&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52498&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52498&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52498&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52498&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52498&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52498&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52498&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52498&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52498&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52498&r=mysqlcfg
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1
ID: 52501
Comment by: f...@php.net
Reported by:marekroman1 at gmail dot com
Summary:Misconfigured Sendmail sends PHP-FPM into an
infinite loop
Status: Analyzed
Type: Bug
Package:FPM related
Operating System: DebianLenny2.6.26-2-openvz-amd64
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
the problem does not exist when using kqueue,poll or select on openbsd
(and
certainely on freebsd also).
the problem exists on linux when using epoll,poll or select.
It's all the problem of the libevent when forking.
Previous Comments:
[2010-07-31 03:23:51] f...@php.net
when calling the mail() function on unix, there is a fork to run the
sendmail command. If the sendmail does not return
quickly and FPM tries to kill the process because of
request_terminate_timeout the bug happens.
Here is a sample C code to simulate a bug sendmail config:
// sendmail_bug.c
#include
int main() {
char buf[11];
while (1) {
read(0, buf, 10);
}
return 0;
}
gcc -o /tmp/sendmail_bug sendmail_bug.c
then configure your php.ini this way:
sendmail_path = /tmp/sendmail_bug
set request_terminate_timeout to a 5s and load a page with the mail
function.
[2010-07-31 00:25:45] marekroman1 at gmail dot com
Description:
(Misconfigured) Sendmail sends PHP-FPM into an infinite loop of
spawning/exiting worker processes when attempting to send an email
through the mail() function. (The php script itself just times out
without any output.)
Since this loop produces 100% cpu load and warnings AND logs these
warnings, the log file has grown to 400MB+ before I noticed the load
spike and stopped PHP-FPM master process with kill -9 PID (nothing else
worked e.g. -QUIT).
After I purge-removed the Sendmail package and installed Postfix
instead, everything is working as it should (I didn't made any changes
to nginx/php-fpm/php config files whatsoever).
Server: nginx-0.8.47
PHP ini settings related to mail: "sendmail_path = /usr/sbin/sendmail -t
-i"
Sendmail state: daemon was not running (sendmail process was called, it
did it's work i.e. nothing, then exited)
PHP configure:
./configure --prefix=/usr --enable-fpm --disable-rpath --with-pear
--disable-debug --with-openssl --with-pcre-regex --with-zlib
--enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-exif
--enable-inline-optimization --with-gd --enable-gd-native-ttf
--with-gettext --with-imap --with-imap-ssl --with-kerberos --with-ldap
--enable-mbstring --enable-mbregex --with-mcrypt --with-mysql
--with-mysqli --enable-pcntl --enable-pdo --with-pdo-firebird
--with-pdo-mysql --with-pdo-pgsql --with-pgsql --enable-shmop
--enable-soap --enable-sockets --enable-sqlite-utf8 --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-xsl --enable-zip --with-pic --enable-ftp
--enable-dom --enable-xmlwriter --enable-xmlreader --enable-tokenizer
--enable-simplexml --enable-session --enable-posix --enable-phar
--enable-libxml --enable-json --with-iconv --enable-filter
--enable-fileinfo --enable-dba --enable-ctype
Dynamic extensions:
pecl apc-beta (apc.so) and rar (rar.so).
Changed PHP-FPM settings:
listen = /var/run/php-fpm/php-fpm.sock
listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 6
request_terminate_timeout = 60
rlimit_files = 10240
chdir = /var/www
catch_workers_output = yes
Test script:
---
$to = 'x...@abc.com';
// subject
$subject = 'Birthday Reminders for August';
// message
$message = '
Birthday Reminders for August
Here are the birthdays upcoming in August!
PersonDayMonthYear
Joe3rdAugust1970
Sally17thAugust1973
';
// To send HTML mail, the Content-type header must be set
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
// Additional headers
$headers .= 'To: Dude Dudeson , Kelly ' .
"\r\n";
$headers .= 'From: Birthday Reminder ' . "\r\n";
$headers .= 'Cc: topstal...@thehomeofallinternetpredators.com' .
"\r\n";
// Mail it
if (mail($to, $subject, $message, $headers)) echo "OKAY!";
Expected result:
OKAY!
Actual result:
--
php-fpm error log:
...
Trying to run a mail script
...
Jul 28 11:42:20.16902
Bug #52609 [PATCH]: session.save_path in php-fpm does not handle ";" in extended format correctly
Edit report at http://bugs.php.net/bug.php?id=52609&edit=1
ID: 52609
Patch added by: f...@php.net
Reported by:rsyring at gmail dot com
Summary:session.save_path in php-fpm does not handle ";" in
extended format correctly
Status: Analyzed
Type: Bug
Package:FPM related
Operating System: ubuntu 10.04
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: php-fpm.ini_scanner_normal.patch
Revision: 1281890269
URL:
http://bugs.php.net/patch-display.php?bug=52609&patch=php-fpm.ini_scanner_normal.patch&revision=1281890269
Previous Comments:
[2010-08-15 16:41:30] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-15 05:56:41] rsyring at gmail dot com
Description:
Version Explanation
=
I am using 5.3.2-1ubuntu4.2 with the php-fpm package from here:
https://launchpad.net/~brianmercer/+archive/php
Sorry for mis-representing my version, but I don't have a good method at
the moment for getting 5.3.3 on Lucid. Also, I checked the changelog
here:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/sapi/fpm/fpm/
For any changes since the PPA was built and I did not see anything
related to this particular issue, so it seems reasonable to assume this
bug has not been fixed.
It looks to me like php-fpm configuration parsing is not handling
semi-colons inside of quotes correctly.
The following value works correctly when set in php.ini:
session.save_path = "0;0660;/home/webuser/tmp/php_sessions"
The following value works correctly when set in php-fcm.conf
php_admin_value[session.save_path] = "/home/webuser/tmp/php_sessions"
By "works correctly" I mean that session files are saved to the target
directory and the correct value is shown in phpinfo().
Expected result:
With the following value set in a php-fcm.conf file:
php_admin_value[session.save_path] =
"0;0660;/home/webuser/tmp/php_sessions"
I would expect to see:
* sessions saved in /home/webuser/tmp/php_sessions
* a mask of 0660 being used
* expect to see "0;0660;/home/webuser/tmp/php_sessions" in the phpinfo()
output for session.save_path
Actual result:
--
I actually see an error message when trying to use sessions:
Warning: session_start(): open("0\/sess_9bite7f0iknrudokl1j080i5c7,
O_RDWR) failed: No such file or directory
and '"0' in the phpinfo() output for session.save_path
--
Edit this bug report at http://bugs.php.net/bug.php?id=52609&edit=1
Bug #52609 [PATCH]: session.save_path in php-fpm does not handle ";" in extended format correctly
Edit report at http://bugs.php.net/bug.php?id=52609&edit=1
ID: 52609
Patch added by: f...@php.net
Reported by:rsyring at gmail dot com
Summary:session.save_path in php-fpm does not handle ";" in
extended format correctly
Status: Assigned
Type: Bug
Package:FPM related
Operating System: ubuntu 10.04
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: php-fpm.ini_scanner_normal.patch
Revision: 1282210234
URL:
http://bugs.php.net/patch-display.php?bug=52609&patch=php-fpm.ini_scanner_normal.patch&revision=1282210234
Previous Comments:
[2010-08-16 15:33:32] rsyring at gmail dot com
Thanks for working on this. I am sorry that I can't currently test the
snapshot or patch as I am limited to working with ubuntu packages at the
moment. I may be able to eventually get some custom packages configured
and compiled, but that won't be for another month or two at least.
----
[2010-08-15 18:39:27] f...@php.net
Can you please try the attached patch ?
Thx
----
[2010-08-15 18:37:49] f...@php.net
The following patch has been added/updated:
Patch Name: php-fpm.ini_scanner_normal.patch
Revision: 1281890269
URL:
http://bugs.php.net/patch-display.php?bug=52609&patch=php-fpm.ini_scanner_normal.patch&revision=1281890269
[2010-08-15 16:41:30] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-15 05:56:41] rsyring at gmail dot com
Description:
Version Explanation
=
I am using 5.3.2-1ubuntu4.2 with the php-fpm package from here:
https://launchpad.net/~brianmercer/+archive/php
Sorry for mis-representing my version, but I don't have a good method at
the moment for getting 5.3.3 on Lucid. Also, I checked the changelog
here:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/sapi/fpm/fpm/
For any changes since the PPA was built and I did not see anything
related to this particular issue, so it seems reasonable to assume this
bug has not been fixed.
It looks to me like php-fpm configuration parsing is not handling
semi-colons inside of quotes correctly.
The following value works correctly when set in php.ini:
session.save_path = "0;0660;/home/webuser/tmp/php_sessions"
The following value works correctly when set in php-fcm.conf
php_admin_value[session.save_path] = "/home/webuser/tmp/php_sessions"
By "works correctly" I mean that session files are saved to the target
directory and the correct value is shown in phpinfo().
Expected result:
With the following value set in a php-fcm.conf file:
php_admin_value[session.save_path] =
"0;0660;/home/webuser/tmp/php_sessions"
I would expect to see:
* sessions saved in /home/webuser/tmp/php_sessions
* a mask of 0660 being used
* expect to see "0;0660;/home/webuser/tmp/php_sessions" in the phpinfo()
output for session.save_path
Actual result:
--
I actually see an error message when trying to use sessions:
Warning: session_start(): open("0\/sess_9bite7f0iknrudokl1j080i5c7,
O_RDWR) failed: No such file or directory
and '"0' in the phpinfo() output for session.save_path
--
Edit this bug report at http://bugs.php.net/bug.php?id=52609&edit=1
Bug #52609 [Com]: session.save_path in php-fpm does not handle ";" in extended format correctly
Edit report at http://bugs.php.net/bug.php?id=52609&edit=1 ID: 52609 Comment by: f...@php.net Reported by:rsyring at gmail dot com Summary:session.save_path in php-fpm does not handle ";" in extended format correctly Status: Assigned Type: Bug Package:FPM related Operating System: ubuntu 10.04 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: this new revision corrects also the same problem when passing INI variable from the fastcgi client (PHP_VALUE and PHP_ADMIN_VALUE) Previous Comments: [2010-08-19 11:30:34] f...@php.net The following patch has been added/updated: Patch Name: php-fpm.ini_scanner_normal.patch Revision: 1282210234 URL: http://bugs.php.net/patch-display.php?bug=52609&patch=php-fpm.ini_scanner_normal.patch&revision=1282210234 [2010-08-16 15:33:32] rsyring at gmail dot com Thanks for working on this. I am sorry that I can't currently test the snapshot or patch as I am limited to working with ubuntu packages at the moment. I may be able to eventually get some custom packages configured and compiled, but that won't be for another month or two at least. ---- [2010-08-15 18:39:27] f...@php.net Can you please try the attached patch ? Thx ---- [2010-08-15 18:37:49] f...@php.net The following patch has been added/updated: Patch Name: php-fpm.ini_scanner_normal.patch Revision: 1281890269 URL: http://bugs.php.net/patch-display.php?bug=52609&patch=php-fpm.ini_scanner_normal.patch&revision=1281890269 [2010-08-15 16:41:30] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52609 -- Edit this bug report at http://bugs.php.net/bug.php?id=52609&edit=1
Bug #52045 [PATCH]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Patch added by: f...@php.net Reported by:FractalizeR at yandex dot ru Summary:Incorrect php.ini file detection Status: Assigned Type: Bug Package:FPM related Operating System: CentOS 5.5 PHP Version:5.3.2 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1282322733 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1282322733 Previous Comments: [2010-07-23 13:36:49] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1279885008 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1279885008 [2010-07-22 23:18:16] f...@php.net Can you please test and report the result. thx ++ Jerome [2010-06-15 12:02:57] paj...@php.net cd php-src patch < patchfile [2010-06-15 11:59:29] FractalizeR at yandex dot ru How do I correctly apply it? patch -d -i ? [2010-06-11 14:11:29] f...@php.net Can you please try the attached patch on trunk ? It must be also working on branche/PHP_5_3. ++ jerome The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52045 -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
[PHP-BUG] Req #52659 [NEW]: change FPM processes title according to their type
From: fat Operating system: * PHP version: 5.3.3 Package: FPM related Bug Type: Feature/Change Request Bug description:change FPM processes title according to their type Description: each FPM process have the same name (the command line used to launched it). It would be great to name them according to their type. The master process: "php-fpm: master process (path/to/conf/file)" The children processes: "php-fpm: pool www.foo.bar" Test script: --- #!/bin/sh ps a | grep fpm Expected result: 21744 pts/3S+ 0:00 php-fpm: master process (/usr/local/php-trunk/etc/php- fpm.conf) 21745 pts/3S+ 0:00 php-fpm: pool www_chroot 21746 pts/3S+ 0:00 php-fpm: pool www_direct Actual result: -- 23464 pts/3S+ 0:00 ./sapi/fpm/php-fpm 23465 pts/3S+ 0:00 ./sapi/fpm/php-fpm 23466 pts/3S+ 0:00 ./sapi/fpm/php-fpm -- Edit bug report at http://bugs.php.net/bug.php?id=52659&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52659&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52659&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52659&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52659&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52659&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52659&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52659&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52659&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52659&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52659&r=support Expected behavior: http://bugs.php.net/fix.php?id=52659&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52659&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52659&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52659&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52659&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52659&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52659&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52659&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52659&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52659&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52659&r=mysqlcfg
[PHP-BUG] Req #52660 [NEW]: change FPM processes title according to their type
From: fat Operating system: * PHP version: 5.3.3 Package: FPM related Bug Type: Feature/Change Request Bug description:change FPM processes title according to their type Description: each FPM process have the same name (the command line used to launched it). It would be great to name them according to their type. The master process: "php-fpm: master process (path/to/conf/file)" The children processes: "php-fpm: pool www.foo.bar" Test script: --- #!/bin/sh ps a | grep fpm Expected result: 21744 pts/3S+ 0:00 php-fpm: master process (/usr/local/php-trunk/etc/php- fpm.conf) 21745 pts/3S+ 0:00 php-fpm: pool www_chroot 21746 pts/3S+ 0:00 php-fpm: pool www_direct Actual result: -- 23464 pts/3S+ 0:00 ./sapi/fpm/php-fpm 23465 pts/3S+ 0:00 ./sapi/fpm/php-fpm 23466 pts/3S+ 0:00 ./sapi/fpm/php-fpm -- Edit bug report at http://bugs.php.net/bug.php?id=52660&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52660&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52660&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52660&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52660&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52660&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52660&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52660&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52660&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52660&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52660&r=support Expected behavior: http://bugs.php.net/fix.php?id=52660&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52660&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52660&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52660&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52660&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52660&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52660&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52660&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52660&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52660&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52660&r=mysqlcfg
Bug #52674 [Com]: [FPM] Status page returns inconsistent Content-Type headers
Edit report at http://bugs.php.net/bug.php?id=52674&edit=1 ID: 52674 Comment by: f...@php.net Reported by:php-bugs at majkl578 dot cz Summary:[FPM] Status page returns inconsistent Content-Type headers Status: Analyzed Type: Bug Package:FPM related Operating System: Linux Debian PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: Moreover, the Content-Type used for json was not the best choice. It was application/jsonrequest. As specified in RFC4627, it should be application/json. Previous Comments: [2010-08-23 10:28:43] f...@php.net The status page does not return a valid Content-Type header: ... text/plain Content-type: text/plain ... it should be ... Content-type: text/plain ... It affects apache but also any other front web servers. Nginx is more tolerant and ignores unknown / malformed headers but text/html was use instead. [2010-08-23 04:23:08] php-bugs at majkl578 dot cz Description: Apache 2 ends up with an error while trying to get content of /status url. Ping url works fine. Same problem with /status?json and /status?html. Apache version: 2.2.16, mpm-worker mod_fastcgi version: 2.4.6 Test script: --- FastCGIExternalServer /php5-fpm-handler -socket "/var/run/php5-fpm.sock" AddHandler php5-fcgi .php SetHandler php5-fcgi-virt Action php5-fcgi-virt /php5-fpm-handler.fcgi virtual Action php5-fcgi /php5-fpm-handler.fcgi ScriptAlias /php5-fpm-handler.fcgi /php5-fpm-handler Expected result: FPM status page Actual result: -- 500 Internal error Logged in Apache's error log: [Mon Aug 23 04:16:55 2010] [error] [client 127.0.0.1] FastCGI: comm with server "/php5-fpm-handler" aborted: error parsing headers: malformed header 'text/plain' -- Edit this bug report at http://bugs.php.net/bug.php?id=52674&edit=1
Bug #52045 [PATCH]: FPM tries to open php.ini from the current dir
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Patch added by: f...@php.net Reported by:FractalizeR at yandex dot ru Summary:FPM tries to open php.ini from the current dir Status: Assigned Type: Bug Package:FPM related Operating System: CentOS 5.5 PHP Version:5.3.2 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch.txt Revision: 1282672877 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch.txt&revision=1282672877 Previous Comments: [2010-08-20 18:45:33] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1282322733 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1282322733 [2010-07-23 13:36:49] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1279885008 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1279885008 ---- [2010-07-22 23:18:16] f...@php.net Can you please test and report the result. thx ++ Jerome [2010-06-15 12:02:57] paj...@php.net cd php-src patch < patchfile [2010-06-15 11:59:29] FractalizeR at yandex dot ru How do I correctly apply it? patch -d -i ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52045 -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
[PHP-BUG] Req #52691 [NEW]: allow multiple instance of FPM using a custom prefix
From: fat
Operating system: *
PHP version: 5.3.3
Package: FPM related
Bug Type: Feature/Change Request
Bug description:allow multiple instance of FPM using a custom prefix
Description:
Like nginx (nginx -p) or apache (httpd -d), FPM should have a command line
option to set a custom prefix on which all relative file path can depend
on.
"php-fpm -p /var/www" will look for /var/www/etc/php-fpm.conf.
pid=logs/php-fpm.pid ; will expand to /var/www/logs/php-fpm.pid
...
Moreover it could be great to have a custom prefix per pool also.
php-fpm -p /var/www
; /var/www/etc/php-fpm.conf
pid=logs/php-fpm.pid
[www1]
prefix = www1 ; expand to /var/www/www1
include = fpm.default.conf
[www2]
prefix = www2 ; expand to /var/www/www2
include = fpm.default.conf
; fpm.default.conf
listen = logs/php-fpm.sock ; expand to /var/www/www{1,2}/logs/php-fpm.sock
pm = static
pm.max_children = 50
slowlog = logs/php-fpm.slowlog ; expand to /var/www/www{1,2}/logs/php-
fpm.slowlog
chroot = $prefix ; expand to /var/www/www{1,2}
chdir = /docs
php_value[error_log] = /logs/php.error.log
...
--
Edit bug report at http://bugs.php.net/bug.php?id=52691&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52691&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52691&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52691&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52691&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52691&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52691&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52691&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52691&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52691&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52691&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52691&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52691&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52691&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52691&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52691&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52691&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52691&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52691&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52691&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52691&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52691&r=mysqlcfg
[PHP-BUG] Req #52692 [NEW]: allow to test and validate FPM conf file from command line
From: fat Operating system: * PHP version: 5.3.3 Package: FPM related Bug Type: Feature/Change Request Bug description:allow to test and validate FPM conf file from command line Description: Like nginx and apache (with the -t argument), FPM should be able to be ran with the -t argument to test and validate the FPM conf file. Test script: --- root# php-fpm -t the configuration file /usr/local/php/etc/php-fpm.conf syntax is ok configuration file /usr/local/php/etc/php-fpm.conf test is successful -- Edit bug report at http://bugs.php.net/bug.php?id=52692&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52692&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52692&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52692&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52692&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52692&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52692&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52692&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52692&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52692&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52692&r=support Expected behavior: http://bugs.php.net/fix.php?id=52692&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52692&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52692&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52692&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52692&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52692&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52692&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52692&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52692&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52692&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52692&r=mysqlcfg
[PHP-BUG] Bug #52693 [NEW]: configuration file errors are not logged to stderr
From: fat Operating system: * PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:configuration file errors are not logged to stderr Description: When FPM is launched, if there is an error which prevents FPM from starting, nothing is written to stderr. Everyhting is logged to error_log only. Test script: --- set a non sense value in php-fpm.conf: listen=/tmp/php-fpm.sock listen.user = nobody listen.group = johndoe Expected result: r...@wild:/LIBRE/dev/php-src/trunk# ./sapi/fpm/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# ps aux | grep php-fpm root 5473 0.0 0.0 2420 816 pts/3S+ 23:29 0:00 grep php-fpm r...@wild:/LIBRE/dev/php-src/trunk# tail -n 1 /tmp/php-fpm/php-fpm.log Aug 24 23:29:35.774255 [ERROR] pid 5471, fpm_unix_resolve_socket_premissions(), line 61: [pool www_chroot] cannot get gid for group 'johndoe': Success (0) Actual result: -- r...@wild:/LIBRE/dev/php-src/trunk# ./sapi/fpm/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# ps ax | grep php-fpm 5579 ?Ss 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5580 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5581 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5582 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# tail -n 1 /tmp/php-fpm/php-fpm.log Aug 24 23:31:54.094551 [NOTICE] pid 5579, fpm_event_loop(), line 111: ready to handle connections -- Edit bug report at http://bugs.php.net/bug.php?id=52693&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52693&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52693&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52693&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52693&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52693&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52693&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52693&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52693&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52693&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52693&r=support Expected behavior: http://bugs.php.net/fix.php?id=52693&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52693&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52693&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52693&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52693&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52693&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52693&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52693&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52693&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52693&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52693&r=mysqlcfg
Bug #52693 [PATCH]: configuration file errors are not logged to stderr
Edit report at http://bugs.php.net/bug.php?id=52693&edit=1 ID: 52693 Patch added by: f...@php.net Reported by: f...@php.net Summary:configuration file errors are not logged to stderr Status: Open Type: Bug Package:FPM related Operating System: * PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-stderr.v1.patch Revision: 1282688485 URL: http://bugs.php.net/patch-display.php?bug=52693&patch=fpm-stderr.v1.patch&revision=1282688485 Previous Comments: [2010-08-24 23:35:40] f...@php.net Description: When FPM is launched, if there is an error which prevents FPM from starting, nothing is written to stderr. Everyhting is logged to error_log only. Test script: --- set a non sense value in php-fpm.conf: listen=/tmp/php-fpm.sock listen.user = nobody listen.group = johndoe Expected result: r...@wild:/LIBRE/dev/php-src/trunk# ./sapi/fpm/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# ps aux | grep php-fpm root 5473 0.0 0.0 2420 816 pts/3S+ 23:29 0:00 grep php-fpm r...@wild:/LIBRE/dev/php-src/trunk# tail -n 1 /tmp/php-fpm/php-fpm.log Aug 24 23:29:35.774255 [ERROR] pid 5471, fpm_unix_resolve_socket_premissions(), line 61: [pool www_chroot] cannot get gid for group 'johndoe': Success (0) Actual result: -- r...@wild:/LIBRE/dev/php-src/trunk# ./sapi/fpm/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# ps ax | grep php-fpm 5579 ?Ss 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5580 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5581 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm 5582 ?S 0:00 ./sapi/fpm/php-fpm -p /tmp/php-fpm r...@wild:/LIBRE/dev/php-src/trunk# tail -n 1 /tmp/php-fpm/php-fpm.log Aug 24 23:31:54.094551 [NOTICE] pid 5579, fpm_event_loop(), line 111: ready to handle connections -- Edit this bug report at http://bugs.php.net/bug.php?id=52693&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
For information, the listen.backlog default value has been changed from
-1 to
128 into trunk recentely: http://svn.php.net/viewvc?
view=revision&revision=302725
This changed won't be applied to 5.3 branch so as the ondemand process
manager
as it's a (big ?) new feature. It could be discussed.
I like the listen_backlog adjustment. It was maybe not perfect but
setting it to
0 will make the on demand PM not working.
for the "else if" fix, you have to add an "else {}" in all the cases. If
there
is a bug somewhere else, it's not advised to have a case which could not
be
checked.
it looks great. Can you also provides test results ?
thx a LOT for you help and your time making PHP better.
Previous Comments:
[2010-08-26 00:15:47] mplomer at gmx dot de
I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:
set listen_backlog default to 128 (to be discussed?)
removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )
renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)
fixed "else if (wp->config->pm == PM_STYLE_ONDEMAND)" in fpm_conf.c (was
only "else" before)
removed config->pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)
log libevent version in fpm_event_init_main
updated some comments in sample config
----
[2010-08-24 00:54:04] f...@php.net
I did some adjustements.
I've added two configuration directives:
; The minimum delay (in µs) between two consecutive forks.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 100µs
;pm.min_delay_between_fork = 100
; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
;pm.ondemand_process_timeout = 10s;
Moreover, I've added a check on the listen.backlog directive which has
to be
greater than pm.max_children when the 'ondemand' PM is used. If the
backlog
queue is smaller than pm.max_children the libevent can't detect incoming
connections.
[2010-08-24 00:51:25] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v2.patch.txt
Revision: 1282603885
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v2.patch.txt&revision=1282603885
[2010-08-10 19:59:55] mplomer at gmx dot de
Thanks. Now it's clear, why setting start_servers = 0 does not work :-)
First of all, I updated the appended patch to work with PHP 5.3 branch
(see attachment). The first tests work very well. I'll do some more
tests the next days.
[2010-08-09 22:14:10] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand-pm
Revision: 1281384850
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand-pm&revision=1281384850
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Req #52569 [PATCH]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Patch added by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-ondemand.v4.patch
Revision: 1282890440
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v4.patch&revision=1282890440
Previous Comments:
[2010-08-26 00:27:45] f...@php.net
For information, the listen.backlog default value has been changed from
-1 to
128 into trunk recentely: http://svn.php.net/viewvc?
view=revision&revision=302725
This changed won't be applied to 5.3 branch so as the ondemand process
manager
as it's a (big ?) new feature. It could be discussed.
I like the listen_backlog adjustment. It was maybe not perfect but
setting it to
0 will make the on demand PM not working.
for the "else if" fix, you have to add an "else {}" in all the cases. If
there
is a bug somewhere else, it's not advised to have a case which could not
be
checked.
it looks great. Can you also provides test results ?
thx a LOT for you help and your time making PHP better.
[2010-08-26 00:15:47] mplomer at gmx dot de
I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:
set listen_backlog default to 128 (to be discussed?)
removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )
renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)
fixed "else if (wp->config->pm == PM_STYLE_ONDEMAND)" in fpm_conf.c (was
only "else" before)
removed config->pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)
log libevent version in fpm_event_init_main
updated some comments in sample config
----
[2010-08-24 00:54:04] f...@php.net
I did some adjustements.
I've added two configuration directives:
; The minimum delay (in µs) between two consecutive forks.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 100µs
;pm.min_delay_between_fork = 100
; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
;pm.ondemand_process_timeout = 10s;
Moreover, I've added a check on the listen.backlog directive which has
to be
greater than pm.max_children when the 'ondemand' PM is used. If the
backlog
queue is smaller than pm.max_children the libevent can't detect incoming
connections.
[2010-08-24 00:51:25] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v2.patch.txt
Revision: 1282603885
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v2.patch.txt&revision=1282603885
[2010-08-10 19:59:55] mplomer at gmx dot de
Thanks. Now it's clear, why setting start_servers = 0 does not work :-)
First of all, I updated the appended patch to work with PHP 5.3 branch
(see attachment). The first tests work very well. I'll do some more
tests the next days.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
here is a new revision:
1- I restore the backlog value check at startup. It's been simplified.
If it's
lower than 128, it's set to 128. I kept also the change of the backlog
default
value from -1 to 128. As the ondemand will certainely end up in trunk,
it's not
a violation of the 5.3 code.
2- you were right for the "else if (wp->config->pm ==
PM_STYLE_ONDEMAND)". I
thought there were a "if (wp->config->pm == PM_STYLE_STATIC)" on the
front of
the block
3- I change the libevent callback on pool listen_socket to prevent CPU
burns. If
max_childre is triggered, the callback function will be set up at next
process
maintenance call (every 1s).
Previous Comments:
--------
[2010-08-27 08:27:20] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v4.patch
Revision: 1282890440
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v4.patch&revision=1282890440
--------
[2010-08-26 00:27:45] f...@php.net
For information, the listen.backlog default value has been changed from
-1 to
128 into trunk recentely: http://svn.php.net/viewvc?
view=revision&revision=302725
This changed won't be applied to 5.3 branch so as the ondemand process
manager
as it's a (big ?) new feature. It could be discussed.
I like the listen_backlog adjustment. It was maybe not perfect but
setting it to
0 will make the on demand PM not working.
for the "else if" fix, you have to add an "else {}" in all the cases. If
there
is a bug somewhere else, it's not advised to have a case which could not
be
checked.
it looks great. Can you also provides test results ?
thx a LOT for you help and your time making PHP better.
[2010-08-26 00:15:47] mplomer at gmx dot de
I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:
set listen_backlog default to 128 (to be discussed?)
removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )
renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)
fixed "else if (wp->config->pm == PM_STYLE_ONDEMAND)" in fpm_conf.c (was
only "else" before)
removed config->pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)
log libevent version in fpm_event_init_main
updated some comments in sample config
[2010-08-24 00:54:04] f...@php.net
I did some adjustements.
I've added two configuration directives:
; The minimum delay (in µs) between two consecutive forks.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 100µs
;pm.min_delay_between_fork = 100
; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
;pm.ondemand_process_timeout = 10s;
Moreover, I've added a check on the listen.backlog directive which has
to be
greater than pm.max_children when the 'ondemand' PM is used. If the
backlog
queue is smaller than pm.max_children the libevent can't detect incoming
connections.
[2010-08-24 00:51:25] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v2.patch.txt
Revision: 1282603885
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v2.patch.txt&revision=1282603885
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
Updates to come:
1- there is a bug. after fork, child process seems to run code reverved
to the
parent process:
Aug 27 08:32:30.646905 [WARNING] pid 4335, fpm_stdio_child_said(), line
143:
[pool www_chroot] child 4450 said into stderr: "Aug 27 08:32:30.628866
[DEBUG]
pid 4450, fpm_pctl_on_socket_accept(), line 529: [pool www_chroot] got
accept
without idle child available I forked, now=22184178.981102"
2- the 1s max delay before resetting the fpm_pctl_on_socket_accept() is
in
theory enough. But I prefer to set a much smaller specific timer (~1ms)
just in
case. Imagine there is a bug and children becomes to segfault and it's
not
restarted. There will be a 1s delay (max) before it's forked again. I
now it's
the worst case scenario.
Previous Comments:
----
[2010-08-27 08:31:11] f...@php.net
here is a new revision:
1- I restore the backlog value check at startup. It's been simplified.
If it's
lower than 128, it's set to 128. I kept also the change of the backlog
default
value from -1 to 128. As the ondemand will certainely end up in trunk,
it's not
a violation of the 5.3 code.
2- you were right for the "else if (wp->config->pm ==
PM_STYLE_ONDEMAND)". I
thought there were a "if (wp->config->pm == PM_STYLE_STATIC)" on the
front of
the block
3- I change the libevent callback on pool listen_socket to prevent CPU
burns. If
max_childre is triggered, the callback function will be set up at next
process
maintenance call (every 1s).
----
[2010-08-27 08:27:20] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-ondemand.v4.patch
Revision: 1282890440
URL:
http://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v4.patch&revision=1282890440
----
[2010-08-26 00:27:45] f...@php.net
For information, the listen.backlog default value has been changed from
-1 to
128 into trunk recentely: http://svn.php.net/viewvc?
view=revision&revision=302725
This changed won't be applied to 5.3 branch so as the ondemand process
manager
as it's a (big ?) new feature. It could be discussed.
I like the listen_backlog adjustment. It was maybe not perfect but
setting it to
0 will make the on demand PM not working.
for the "else if" fix, you have to add an "else {}" in all the cases. If
there
is a bug somewhere else, it's not advised to have a case which could not
be
checked.
it looks great. Can you also provides test results ?
thx a LOT for you help and your time making PHP better.
[2010-08-26 00:15:47] mplomer at gmx dot de
I did some finetuning and cleanups in the fpm-ondemand-pm-v3.patch:
set listen_backlog default to 128 (to be discussed?)
removed listen_backlog adjustment (I considered that it is enough to
leave the default at 128, a greater value is mostly ignored by the
system anyway, and the number of requests in the backlog has rather
nothing to do with max_children. If you do not agree with this, feel
free to restore the old behaviour :-) )
renamed ondemand_process_timeout to process_idle_timeout (it's better, I
think)
fixed "else if (wp->config->pm == PM_STYLE_ONDEMAND)" in fpm_conf.c (was
only "else" before)
removed config->pm_(start/min_spare/max_spare)_servers = 0; ... in
fpm_conf.c (should not be used anyway when pm = ondemand)
log libevent version in fpm_event_init_main
updated some comments in sample config
[2010-08-24 00:54:04] f...@php.net
I did some adjustements.
I've added two configuration directives:
; The minimum delay (in µs) between two consecutive forks.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 100µs
;pm.min_delay_between_fork = 100
; The number of seconds after which an idle process will be killed.
; Note: Used only when pm is set to 'ondemand'
; Default Value: 10s
;pm.ondemand_process_timeout = 10s;
Moreover, I've added a check on the listen.backlog directive which has
to be
greater than pm.max_children when the '
Bug #52725 [PATCH]: undefined reference to `__sync_bool_compare_and_swap_4'
Edit report at http://bugs.php.net/bug.php?id=52725&edit=1 ID: 52725 Patch added by: f...@php.net Reported by:fedora at famillecollet dot com Summary:undefined reference to `__sync_bool_compare_and_swap_4' Status: Assigned Type: Bug Package:FPM related Operating System: GNU/Linux (RHEL 5.5) PHP Version:5.3SVN-2010-08-28 (snap) Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm_builtin_atomic.patch Revision: 1283175955 URL: http://bugs.php.net/patch-display.php?bug=52725&patch=fpm_builtin_atomic.patch&revision=1283175955 Previous Comments: [2010-08-28 22:37:23] fedora at famillecollet dot com Description: Build fails on RHEL/Centos 5 (gcc-4.1.2) sapi/fpm/fpm/fpm_shm_slots.o: In function `fpm_spinlock': /builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:148: undefined reference to `__sync_bool_compare_and_swap_4' /builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:143: undefined reference to `__sync_bool_compare_and_swap_4' This seems linked to commit 302600 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_atomic.h?r1=299794&r2=302600 Changing the test fixes the issue #if (__GNUC__) && (__GNUC__ >= 4 && __GNUC_MINOR__ >= 2) I don't know which is the correct value. Build ok on fedora 12 (gcc-4.4.4) and fedora 13 (gcc-4.4.4) -- Edit this bug report at http://bugs.php.net/bug.php?id=52725&edit=1
Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support
Edit report at http://bugs.php.net/bug.php?id=52419&edit=1 ID: 52419 Comment by: f...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Unable to compile PHP with both Apache2 and FPM support Status: Open Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.3.3 Block user comment: N New Comment: I have a similar issue with the current PHP_5_3. When the php-fpm is built, it's linked against : sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo I think it's somehow related to http://bugs.php.net/52498. Previous Comments: [2010-08-04 10:35:24] ali at aliziad dot clom fyi: I am also getting the same error with php 5.3.3 (/w apxs and fpm) on CentOS -ali [2010-07-23 20:44:23] ras...@php.net You could try it in a clean Debian image using the free vmware player and the images from http://www.thoughtpolice.co.uk/vmware/ Just so you have a clean environment to compare yours against. [2010-07-23 20:39:38] php-bugs at majkl578 dot cz No, I don't, I've only this one. Maybe it's really (somehow) related to my environment, because I'm also unable to compile PHP with pecl binary even if '--with-pear' and '--enable-cli' are set... [2010-07-23 19:38:21] ras...@php.net Do you have access to another Debian box somewhere? Or perhaps a clean VM? A lot of the PHP developers are on Debian, myself included, so it would really surprise me if there was a general compile issue there. And since I can't reproduce it with your exact configure line, there is something about your environment that is different. [2010-07-23 19:35:26] php-bugs at majkl578 dot cz I've reinstalled libapr and libapr-dev, make clean'ed, then reconfigured and re-run compilation. Exactly same error. Compiling them separately works fine. Versions: apache2: 2.2.15-6 libapr and libapr-dev: 1.4.2-3 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52419 -- Edit this bug report at http://bugs.php.net/bug.php?id=52419&edit=1
Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support
Edit report at http://bugs.php.net/bug.php?id=52419&edit=1 ID: 52419 Comment by: f...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Unable to compile PHP with both Apache2 and FPM support Status: Open Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.3.3 Block user comment: N New Comment: The problem is: in the general Makefile there is: BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH) and PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo sapi/fpm/fpm/fpm.lo sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo sapi/fpm/fpm/fpm_env.lo sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo sapi/fpm/fpm/fpm_php.lo sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo sapi/fpm/fpm/fpm_stdio.lo sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo sapi/fpm/fpm/zlog.lo sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo main/internal_functions.lo FPM is linked with apache but the apr lib is not known at compile time. There is the same problem when compiling libphp5.so which is linked agains FPM object files and libevent is not known at compile time: # make libs/libphp5.bundle sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make': /LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381: undefined reference to `event_reinit' Previous Comments: [2010-09-01 12:05:43] f...@php.net I have a similar issue with the current PHP_5_3. When the php-fpm is built, it's linked against : sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo I think it's somehow related to http://bugs.php.net/52498. [2010-08-04 10:35:24] ali at aliziad dot clom fyi: I am also getting the same error with php 5.3.3 (/w apxs and fpm) on CentOS -ali [2010-07-23 20:44:23] ras...@php.net You could try it in a clean Debian image using the free vmware player and the images from http://www.thoughtpolice.co.uk/vmware/ Just so you have a clean environment to compare yours against. [2010-07-23 20:39:38] php-bugs at majkl578 dot cz No, I don't, I've only this one. Maybe it's really (somehow) related to my environment, because I'm also unable to compile PHP with pecl binary even if '--with-pear' and '--enable-cli' are set... [2010-07-23 19:38:21] ras...@php.net Do you have access to another Debian box somewhere? Or perhaps a clean VM? A lot of the PHP developers are on Debian, myself included, so it would really surprise me if there was a general compile issue there. And since I can't reproduce it with your exact configure line, there is something about your environment that is different. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52419 -- Edit this bug report at http://bugs.php.net/bug.php?id=52419&edit=1
Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support
Edit report at http://bugs.php.net/bug.php?id=52419&edit=1 ID: 52419 Comment by: f...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Unable to compile PHP with both Apache2 and FPM support Status: Open Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.3.3 Block user comment: N New Comment: the problem is the same if compiling SAPI apache2handler with litespeed. The same with fpm and litespeed. Is it possible to compile PHP with multiple SAPI ? Previous Comments: [2010-09-01 14:29:49] f...@php.net The problem is: in the general Makefile there is: BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH) and PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo sapi/fpm/fpm/fpm.lo sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo sapi/fpm/fpm/fpm_env.lo sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo sapi/fpm/fpm/fpm_php.lo sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo sapi/fpm/fpm/fpm_stdio.lo sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo sapi/fpm/fpm/zlog.lo sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo main/internal_functions.lo FPM is linked with apache but the apr lib is not known at compile time. There is the same problem when compiling libphp5.so which is linked agains FPM object files and libevent is not known at compile time: # make libs/libphp5.bundle sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make': /LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381: undefined reference to `event_reinit' [2010-09-01 12:05:43] f...@php.net I have a similar issue with the current PHP_5_3. When the php-fpm is built, it's linked against : sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo I think it's somehow related to http://bugs.php.net/52498. [2010-08-04 10:35:24] ali at aliziad dot clom fyi: I am also getting the same error with php 5.3.3 (/w apxs and fpm) on CentOS -ali [2010-07-23 20:44:23] ras...@php.net You could try it in a clean Debian image using the free vmware player and the images from http://www.thoughtpolice.co.uk/vmware/ Just so you have a clean environment to compare yours against. [2010-07-23 20:39:38] php-bugs at majkl578 dot cz No, I don't, I've only this one. Maybe it's really (somehow) related to my environment, because I'm also unable to compile PHP with pecl binary even if '--with-pear' and '--enable-cli' are set... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52419 -- Edit this bug report at http://bugs.php.net/bug.php?id=52419&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1 ID: 52569 Comment by: f...@php.net Reported by:mplomer at gmx dot de Summary:Implement "ondemand" process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: @dennisml at conversis dot de It's complex to do and security risky. Don't want to mess with that. Previous Comments: [2010-09-04 16:26:06] dennisml at conversis dot de Since this patch causes the master process to dynamically fork children on demand I'm wondering if it would be feasible to introduce the possibility to do setuid()/setgid() calls after the fork to run the child process with different user id's? What I'm thinking about is the mass-hosting case that was previously talked about on the mailinglist. Back then this would have been quite a bit of work to do but with this patch this should be much easier to accomplish. [2010-08-30 10:21:37] mplomer at gmx dot de Some test results of the "ondemand"-pm: General - Pool has to start with 0 children - OK - Handling and checking of new config options - OK Concurrent requests - Children has to be forked immediately on new requests without delay - OK - Idle children has to be killed after pm.process_idle_timeout + 0-1s - OK - When there are more than one idle children, kill only one per second PER POOL - OK Reaching pm.max_children limit - No more processes has to be created - OK - Requests have to wait until one child becomes idle and then get handled immediately without further delay - OK - When limit is reached, issue a warning and increase status counter (and do this only once) - OK: Aug 28 13:39:41.537174 [WARNING] pid 27540, fpm_pctl_on_socket_accept(), line 507: [pool www] server reached max_children setting (10), consider raising it - Warning is re-issued after children count decreases and hit the limit again - OK CPU burns - When reaching max_children limit, pause libevent callback and reenable it in the maintenance routine, to avoid CPU burns - OK - When children takes too long to accept() the request, avoid CPU burn - NOTOK -> happens sometimes (in praxis only sometimes after forking) - to reproduce add an usleep(5) in children's code after fork(), or apachebench with ~200 concurrent requests :-) -> You get a lot of: "fpm_pctl_on_socket_accept(), line 502: [pool www] fpm_pctl_on_socket_accept() called" -> It's not a big problem, because this doesn't take much time (in one rare case it took ~90ms on my machine), but it's not nice, especially when the server is flooded with requests -> one idea: - do not re-enable event-callback in fpm_pctl_on_socket_accept - send an event from children just after accept() to parent process - re-enable event-callback in parent process, when it receives this event from children - in case of an error it is re-enabled in the maintainance routine after max 1s, which is IMHO not bad to throttle requests in case of error Stress tests - Test-machine: Intel Core i7 930 (4 x 2.8 GHz) (VMware with 256 MB RAM) - Testing with 100 concurrent requests on the same pool to a sleep(10); php script with 0 running processes and max_children = 200: - took about 4ms per fork in average - 25 processes are forked in one block (timeslice?), after this there is a gap of 200-1000ms - took about 125ms to fork 25 children - took about 2.5s to fork all 100 children and accept the requests - Testing with 200 concurrent requests - hits RAM limit of VM, so it's maybe not meaningful - took ~10.5s to fork all 200 children and accept the requests - Testing with 10 concurrent requests on 20 pools (so in fact 200 concurrent requests) - took ~11.2s to fork all 200 children and accept the requests - all children are killed after process_timeout + 10s (1 process per second per pool is killed) - OK [2010-08-30 10:18:14] mplomer at gmx dot de Patch version 5: - Added missing fpm_globals.is_child check (proposed by jerome) - Implemented "max children reached" status counter. - Fixed missing last_idle_child = NULL; in fpm_pctl_perform_idle_server_maintenance which caused the routine to shutdown only one (or a few?) processes per second globally instead per pool, when you have multiple pools. I think this was not the intention, and it's a bug. [2010-08-27 08:38:34] f...@php.net Updates to come: 1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
You should "make clean" before recompiling with v5 patch.
The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3
branch.
++ Jerome
Previous Comments:
[2010-09-13 03:30:56] dennisml at conversis dot de
Is v5 of the patch known not to work with fpm in php 5.3.3? When
applying the patch I get the following segfault:
Program received signal SIGSEGV, Segmentation fault.
0x005cf319 in fpm_env_conf_wp (wp=)
at /home/dennis/php-5.3.3/sapi/fpm/fpm/fpm_env.c:141
141 if (*kv->value == '$') {
--------
[2010-09-05 20:42:56] f...@php.net
@dennisml at conversis dot de
It's complex to do and security risky. Don't want to mess with that.
[2010-09-04 16:26:06] dennisml at conversis dot de
Since this patch causes the master process to dynamically fork children
on demand I'm wondering if it would be feasible to introduce the
possibility to do setuid()/setgid() calls after the fork to run the
child process with different user id's?
What I'm thinking about is the mass-hosting case that was previously
talked about on the mailinglist. Back then this would have been quite a
bit of work to do but with this patch this should be much easier to
accomplish.
[2010-08-30 10:21:37] mplomer at gmx dot de
Some test results of the "ondemand"-pm:
General
- Pool has to start with 0 children - OK
- Handling and checking of new config options - OK
Concurrent requests
- Children has to be forked immediately on new requests without delay -
OK
- Idle children has to be killed after pm.process_idle_timeout + 0-1s -
OK
- When there are more than one idle children, kill only one per second
PER POOL - OK
Reaching pm.max_children limit
- No more processes has to be created - OK
- Requests have to wait until one child becomes idle and then get
handled immediately without further delay - OK
- When limit is reached, issue a warning and increase status counter
(and do this only once) - OK:
Aug 28 13:39:41.537174 [WARNING] pid 27540,
fpm_pctl_on_socket_accept(), line 507: [pool www] server reached
max_children setting (10), consider raising it
- Warning is re-issued after children count decreases and hit the limit
again - OK
CPU burns
- When reaching max_children limit, pause libevent callback and reenable
it in the maintenance routine, to avoid CPU burns - OK
- When children takes too long to accept() the request, avoid CPU burn -
NOTOK
-> happens sometimes (in praxis only sometimes after forking) - to
reproduce add an usleep(5) in children's code after fork(), or
apachebench with ~200 concurrent requests :-)
-> You get a lot of: "fpm_pctl_on_socket_accept(), line 502: [pool www]
fpm_pctl_on_socket_accept() called"
-> It's not a big problem, because this doesn't take much time (in one
rare case it took ~90ms on my machine), but it's not nice, especially
when the server is flooded with requests
-> one idea:
- do not re-enable event-callback in fpm_pctl_on_socket_accept
- send an event from children just after accept() to parent process
- re-enable event-callback in parent process, when it receives this
event from children
- in case of an error it is re-enabled in the maintainance routine
after max 1s, which is IMHO not bad to throttle requests in case of
error
Stress tests
- Test-machine: Intel Core i7 930 (4 x 2.8 GHz) (VMware with 256 MB
RAM)
- Testing with 100 concurrent requests on the same pool to a sleep(10);
php script with 0 running processes and max_children = 200:
- took about 4ms per fork in average
- 25 processes are forked in one block (timeslice?), after this there
is a gap of 200-1000ms
- took about 125ms to fork 25 children
- took about 2.5s to fork all 100 children and accept the requests
- Testing with 200 concurrent requests
- hits RAM limit of VM, so it's maybe not meaningful
- took ~10.5s to fork all 200 children and accept the requests
- Testing with 10 concurrent requests on 20 pools (so in fact 200
concurrent requests)
- took ~11.2s to fork all 200 children and acce
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1
ID: 52501
Patch added by: f...@php.net
Reported by:marekroman1 at gmail dot com
Summary:Misconfigured Sendmail sends PHP-FPM into an
infinite loop
Status: Analyzed
Type: Bug
Package:FPM related
Operating System: DebianLenny2.6.26-2-openvz-amd64
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-nomorelibevent.v2.patch
Revision: 1284478582
URL:
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v2.patch&revision=1284478582
Previous Comments:
[2010-07-31 21:46:46] marekroman1 at gmail dot com
Oh, thanks fat.
[2010-07-31 17:25:58] f...@php.net
the problem does not exist when using kqueue,poll or select on openbsd
(and
certainely on freebsd also).
the problem exists on linux when using epoll,poll or select.
It's all the problem of the libevent when forking.
[2010-07-31 03:23:51] f...@php.net
when calling the mail() function on unix, there is a fork to run the
sendmail command. If the sendmail does not return
quickly and FPM tries to kill the process because of
request_terminate_timeout the bug happens.
Here is a sample C code to simulate a bug sendmail config:
// sendmail_bug.c
#include
int main() {
char buf[11];
while (1) {
read(0, buf, 10);
}
return 0;
}
gcc -o /tmp/sendmail_bug sendmail_bug.c
then configure your php.ini this way:
sendmail_path = /tmp/sendmail_bug
set request_terminate_timeout to a 5s and load a page with the mail
function.
[2010-07-31 00:25:45] marekroman1 at gmail dot com
Description:
(Misconfigured) Sendmail sends PHP-FPM into an infinite loop of
spawning/exiting worker processes when attempting to send an email
through the mail() function. (The php script itself just times out
without any output.)
Since this loop produces 100% cpu load and warnings AND logs these
warnings, the log file has grown to 400MB+ before I noticed the load
spike and stopped PHP-FPM master process with kill -9 PID (nothing else
worked e.g. -QUIT).
After I purge-removed the Sendmail package and installed Postfix
instead, everything is working as it should (I didn't made any changes
to nginx/php-fpm/php config files whatsoever).
Server: nginx-0.8.47
PHP ini settings related to mail: "sendmail_path = /usr/sbin/sendmail -t
-i"
Sendmail state: daemon was not running (sendmail process was called, it
did it's work i.e. nothing, then exited)
PHP configure:
./configure --prefix=/usr --enable-fpm --disable-rpath --with-pear
--disable-debug --with-openssl --with-pcre-regex --with-zlib
--enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-exif
--enable-inline-optimization --with-gd --enable-gd-native-ttf
--with-gettext --with-imap --with-imap-ssl --with-kerberos --with-ldap
--enable-mbstring --enable-mbregex --with-mcrypt --with-mysql
--with-mysqli --enable-pcntl --enable-pdo --with-pdo-firebird
--with-pdo-mysql --with-pdo-pgsql --with-pgsql --enable-shmop
--enable-soap --enable-sockets --enable-sqlite-utf8 --enable-sysvmsg
--enable-sysvsem --enable-sysvshm --with-tidy --enable-wddx
--with-xmlrpc --with-xsl --enable-zip --with-pic --enable-ftp
--enable-dom --enable-xmlwriter --enable-xmlreader --enable-tokenizer
--enable-simplexml --enable-session --enable-posix --enable-phar
--enable-libxml --enable-json --with-iconv --enable-filter
--enable-fileinfo --enable-dba --enable-ctype
Dynamic extensions:
pecl apc-beta (apc.so) and rar (rar.so).
Changed PHP-FPM settings:
listen = /var/run/php-fpm/php-fpm.sock
listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 6
request_terminate_timeout = 60
rlimit_files = 10240
chdir = /var/www
catch_workers_output = yes
Test script:
---
$to = 'x...@abc.com';
// subject
$subject = 'Birthday Reminders for August';
// message
$message = '
Birthday Reminders for August
Here are the birthdays upcoming in August!
PersonDayMonthYear
Joe3rdAugust1970
Sally17thAugust1973
';
// To send HTML mail, the Content-type header must be set
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
// Additional headers
$h
Bug #52796 [PATCH]: Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php
Edit report at http://bugs.php.net/bug.php?id=52796&edit=1 ID: 52796 Patch added by: f...@php.net Reported by:momchil at xaxo dot eu Summary:Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php Status: Assigned Type: Bug Package:FPM related Operating System: linux PHP Version:5.3SVN-2010-09-08 (SVN) Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478708 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v2.patch&revision=1284478708 Previous Comments: [2010-09-10 00:08:56] f...@php.net just follow the current bug and the following http://bugs.php.net/52501 [2010-09-10 00:03:11] momchil at xaxo dot eu ok, can you please point me to the bug report about reloading so that I can follow it and know when it gets fixed? [2010-09-10 00:00:49] f...@php.net you should not use FPM reloading since this bug has not been corrected. Please use restart instead. [2010-09-09 23:57:39] momchil at xaxo dot eu 1,2,4,5 are known. about forking: I thought you mean forking inside php code and did not thought about system(), there is some code using the system() function. reloading: I did not reload fpm at the moment when the crash happened, we are reloading it on fpm.conf/php.ini changes about what I wrote just before on 2010-09-09 21:38 UTC: I was told that the mail() function has been used about 1500 times in a script for sending newsletter, which might be related as you pointed out. I will try without the emergency restart as you suggest, thank you for the pointers and your time investigating this :) [2010-09-09 23:47:47] f...@php.net You have a lots of error in your LOG file: 1- Sep 08 14:10:10.251071 [WARNING] [pool www0] child 13097 said into stderr: "Connection from disallowed IP address '10.13.20.24' is dropped." you should allow those IP address 2- you have a lots of PHP errors which are written to stdout. Search for "said into stderr" in you LOG file. 3- You have calls from external command (rm, convert). when run, php forks for running those command. The problem seem to be similar to bug http://bugs.php.net/52501 4- you have a lot of requests which are executing too slow after 15s and which are ptraced to slowlog. 5- you have a lot of requests which are timeouted after 30s. 6- you have a lot of warning saying your server "seems busy". you should review your configuration file to increase min/max_spare_server. 4- I asked if you did reload FPM. You said no and your LOG file says you had: Sep 08 03:10:07.634996 [NOTICE] using inherited socket fd=6, "10.13.20.26:9910" 5- I asked if your PHP scripts forks somehow. It appears so finaly, the problem occurs when: - some PHP scripts are forking some process (via system() or mail()) - FPM is reloading via emergency_restart_threshold It's a bug related to libevent and forking. I'm on it. You should try disabling emergency_restart_threshold temporarily. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52796 -- Edit this bug report at http://bugs.php.net/bug.php?id=52796&edit=1
Bug #52796 [PATCH]: Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php
Edit report at http://bugs.php.net/bug.php?id=52796&edit=1 ID: 52796 Patch added by: f...@php.net Reported by:momchil at xaxo dot eu Summary:Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php Status: Feedback Type: Bug Package:FPM related Operating System: linux PHP Version:5.3SVN-2010-09-08 (SVN) Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v5.patch Revision: 1284709736 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v5.patch&revision=1284709736 Previous Comments: [2010-09-14 17:38:45] f...@php.net Can you please test the following patch ? This patch removes libevent from FPM. A simple select base event mechanism has been made instead. It should prevent the forking problem when using libevent. [2010-09-14 17:38:28] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478708 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v2.patch&revision=1284478708 ---- [2010-09-10 00:08:56] f...@php.net just follow the current bug and the following http://bugs.php.net/52501 [2010-09-10 00:03:11] momchil at xaxo dot eu ok, can you please point me to the bug report about reloading so that I can follow it and know when it gets fixed? ---- [2010-09-10 00:00:49] f...@php.net you should not use FPM reloading since this bug has not been corrected. Please use restart instead. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52796 -- Edit this bug report at http://bugs.php.net/bug.php?id=52796&edit=1
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1
ID: 52501
Patch added by: f...@php.net
Reported by:marekroman1 at gmail dot com
Summary:Misconfigured Sendmail sends PHP-FPM into an
infinite loop
Status: Feedback
Type: Bug
Package:FPM related
Operating System: DebianLenny2.6.26-2-openvz-amd64
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-nomorelibevent.v5.patch
Revision: 1284709749
URL:
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v5.patch&revision=1284709749
Previous Comments:
[2010-09-14 17:37:55] f...@php.net
Can you please test the following patch ?
This patch removes libevent from FPM. A simple select base event
mechanism has
been made instead. It should prevent the forking problem when using
libevent.
[2010-09-14 17:36:23] f...@php.net
The following patch has been added/updated:
Patch Name: fpm-nomorelibevent.v2.patch
Revision: 1284478582
URL:
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v2.patch&revision=1284478582
[2010-07-31 21:46:46] marekroman1 at gmail dot com
Oh, thanks fat.
[2010-07-31 17:25:58] f...@php.net
the problem does not exist when using kqueue,poll or select on openbsd
(and
certainely on freebsd also).
the problem exists on linux when using epoll,poll or select.
It's all the problem of the libevent when forking.
----
[2010-07-31 03:23:51] f...@php.net
when calling the mail() function on unix, there is a fork to run the
sendmail command. If the sendmail does not return
quickly and FPM tries to kill the process because of
request_terminate_timeout the bug happens.
Here is a sample C code to simulate a bug sendmail config:
// sendmail_bug.c
#include
int main() {
char buf[11];
while (1) {
read(0, buf, 10);
}
return 0;
}
gcc -o /tmp/sendmail_bug sendmail_bug.c
then configure your php.ini this way:
sendmail_path = /tmp/sendmail_bug
set request_terminate_timeout to a 5s and load a page with the mail
function.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52501
--
Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52796 [Com]: Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php
Edit report at http://bugs.php.net/bug.php?id=52796&edit=1 ID: 52796 Comment by: f...@php.net Reported by:momchil at xaxo dot eu Summary:Sep 08 15:22:32.861368 [WARNING] [pool www0] child 25271 said into stderr: "php Status: Feedback Type: Bug Package:FPM related Operating System: linux PHP Version:5.3SVN-2010-09-08 (SVN) Assigned To:fat Block user comment: N New Comment: can you please test the new patch (v5) ? Previous Comments: [2010-09-17 09:48:57] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v5.patch Revision: 1284709736 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v5.patch&revision=1284709736 [2010-09-14 17:38:45] f...@php.net Can you please test the following patch ? This patch removes libevent from FPM. A simple select base event mechanism has been made instead. It should prevent the forking problem when using libevent. [2010-09-14 17:38:28] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478708 URL: http://bugs.php.net/patch-display.php?bug=52796&patch=fpm-nomorelibevent.v2.patch&revision=1284478708 ---- [2010-09-10 00:08:56] f...@php.net just follow the current bug and the following http://bugs.php.net/52501 [2010-09-10 00:03:11] momchil at xaxo dot eu ok, can you please point me to the bug report about reloading so that I can follow it and know when it gets fixed? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52796 -- Edit this bug report at http://bugs.php.net/bug.php?id=52796&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Feedback Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: can you please test the new patch (v5) ? Previous Comments: [2010-09-17 09:49:09] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v5.patch Revision: 1284709749 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v5.patch&revision=1284709749 [2010-09-14 17:37:55] f...@php.net Can you please test the following patch ? This patch removes libevent from FPM. A simple select base event mechanism has been made instead. It should prevent the forking problem when using libevent. [2010-09-14 17:36:23] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v2.patch Revision: 1284478582 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v2.patch&revision=1284478582 [2010-07-31 21:46:46] marekroman1 at gmail dot com Oh, thanks fat. [2010-07-31 17:25:58] f...@php.net the problem does not exist when using kqueue,poll or select on openbsd (and certainely on freebsd also). the problem exists on linux when using epoll,poll or select. It's all the problem of the libevent when forking. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Feedback Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: It's a case I didn't care about as it's a first release debug patch. Thx you very much for your tests and comments. ++ Jerome Previous Comments: [2010-10-03 12:30:18] danger at freebsd dot org well so far it seems to be running pretty fine. Only errors I am seeing now are like this: Oct 03 11:45:51.547273 [WARNING] php_poll2() returns 4 Don't know what it means... [2010-10-02 13:23:10] danger at freebsd dot org I have been experiencing similar problems with a busy site on FreeBSD pretty regurarly as well. I am now testing your patch, will report later how it goes. ---- [2010-09-17 09:49:43] f...@php.net can you please test the new patch (v5) ? ---- [2010-09-17 09:49:09] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v5.patch Revision: 1284709749 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v5.patch&revision=1284709749 ---- [2010-09-14 17:37:55] f...@php.net Can you please test the following patch ? This patch removes libevent from FPM. A simple select base event mechanism has been made instead. It should prevent the forking problem when using libevent. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Patch added by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v6.patch Revision: 1286325458 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v6.patch&revision=1286325458 Previous Comments: [2010-10-03 12:35:23] f...@php.net It's a case I didn't care about as it's a first release debug patch. Thx you very much for your tests and comments. ++ Jerome [2010-10-03 12:30:18] danger at freebsd dot org well so far it seems to be running pretty fine. Only errors I am seeing now are like this: Oct 03 11:45:51.547273 [WARNING] php_poll2() returns 4 Don't know what it means... [2010-10-02 13:23:10] danger at freebsd dot org I have been experiencing similar problems with a busy site on FreeBSD pretty regurarly as well. I am now testing your patch, will report later how it goes. ---- [2010-09-17 09:49:43] f...@php.net can you please test the new patch (v5) ? ---- [2010-09-17 09:49:09] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v5.patch Revision: 1284709749 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v5.patch&revision=1284709749 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Patch added by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Feedback Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v7.patch&revision=1286357775 Previous Comments: [2010-10-06 02:39:23] f...@php.net Can you please test the updated version of the patch ? I'm waiting for your returns to commit. [2010-10-06 02:37:39] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v6.patch Revision: 1286325458 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v6.patch&revision=1286325458 ---- [2010-10-03 12:35:23] f...@php.net It's a case I didn't care about as it's a first release debug patch. Thx you very much for your tests and comments. ++ Jerome [2010-10-03 12:30:18] danger at freebsd dot org well so far it seems to be running pretty fine. Only errors I am seeing now are like this: Oct 03 11:45:51.547273 [WARNING] php_poll2() returns 4 Don't know what it means... [2010-10-02 13:23:10] danger at freebsd dot org I have been experiencing similar problems with a busy site on FreeBSD pretty regurarly as well. I am now testing your patch, will report later how it goes. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Feedback Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: small bug correction. Previous Comments: [2010-10-06 11:36:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v7.patch&revision=1286357775 [2010-10-06 02:39:23] f...@php.net Can you please test the updated version of the patch ? I'm waiting for your returns to commit. [2010-10-06 02:37:39] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v6.patch Revision: 1286325458 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v6.patch&revision=1286325458 ---- [2010-10-03 12:35:23] f...@php.net It's a case I didn't care about as it's a first release debug patch. Thx you very much for your tests and comments. ++ Jerome [2010-10-03 12:30:18] danger at freebsd dot org well so far it seems to be running pretty fine. Only errors I am seeing now are like this: Oct 03 11:45:51.547273 [WARNING] php_poll2() returns 4 Don't know what it means... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Patch added by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v8.patch Revision: 1286628184 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v8.patch&revision=1286628184 Previous Comments: [2010-10-08 23:18:24] mplomer at gmx dot de I did some general tests with patch.v7 (apachebench with hitting the limits; increasing and decreasing server load; ...) and I could not detect any errors. But I did not do any more detailed tests. [2010-10-06 11:36:35] f...@php.net small bug correction. [2010-10-06 11:36:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v7.patch&revision=1286357775 [2010-10-06 02:39:23] f...@php.net Can you please test the updated version of the patch ? I'm waiting for your returns to commit. ---- [2010-10-06 02:37:39] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v6.patch Revision: 1286325458 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v6.patch&revision=1286325458 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: small bug correction. Previous Comments: [2010-10-09 14:43:04] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v8.patch Revision: 1286628184 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v8.patch&revision=1286628184 [2010-10-08 23:18:24] mplomer at gmx dot de I did some general tests with patch.v7 (apachebench with hitting the limits; increasing and decreasing server load; ...) and I could not detect any errors. But I did not do any more detailed tests. [2010-10-06 11:36:35] f...@php.net small bug correction. [2010-10-06 11:36:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v7.patch&revision=1286357775 [2010-10-06 02:39:23] f...@php.net Can you please test the updated version of the patch ? I'm waiting for your returns to commit. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: no problem tony :) Previous Comments: [2010-10-11 14:40:40] tony2...@php.net I'd appreciate if you give me some time to test it in my environment. A week or so would be enough, I guess. [2010-10-09 14:43:20] f...@php.net small bug correction. [2010-10-09 14:43:04] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v8.patch Revision: 1286628184 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v8.patch&revision=1286628184 [2010-10-08 23:18:24] mplomer at gmx dot de I did some general tests with patch.v7 (apachebench with hitting the limits; increasing and decreasing server load; ...) and I could not detect any errors. But I did not do any more detailed tests. [2010-10-06 11:36:35] f...@php.net small bug correction. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: I can't create a specific patch for 5.3.3. If you really want to test on 5.3.3, you can do: tar -xzvf php-5.3.3.tar.gz cd php-5.3.3 rm -rf sapi/fpm wget http://snaps.php.net/php5.3-20101530.tar.gz tar -xzvf php5.3-20101530.tar.gz mv php5.3-20101530/sapi/fpm sapi/fpm rm -rf php5.3-20101530 patch -p0 < fpm-nomorelibevent.v8.patch ./buildconf --force ./configure --enable-fpm --other-configure-args make && make install it should work and you have php 5.3.3 core and up to date and patched FPM. Previous Comments: [2010-10-22 08:23:54] info at hninsider dot com Can we have the patch working with the current 5.3.3 production version. Dev snapshots are not for production use and v8 patch does not apply cleanly to latest production version. Please provide a working patch for latest 5.3.3 ( not dev ) production version. Thank you. [2010-10-11 14:53:59] f...@php.net no problem tony :) [2010-10-11 14:40:40] tony2...@php.net I'd appreciate if you give me some time to test it in my environment. A week or so would be enough, I guess. ---- [2010-10-09 14:43:20] f...@php.net small bug correction. ---- [2010-10-09 14:43:04] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v8.patch Revision: 1286628184 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v8.patch&revision=1286628184 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: f...@php.net
Reported by:mplomer at gmx dot de
Summary:Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package:FPM related
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
New Comment:
> However this could be easily prevented by using disable_functions
> to prevent these and other potentially harmful functions from
> being called (system, exec, etc) which could be used to achieve
> the same goal and are not desirable in a shared hosting environment
anyway.
- it's very complex to do.
- you have no guarantee that nothing will be forgotten (until a security
hole is found)
- you have to maintain this security layer over the time, adding new
functions, ...
- If the sysadm have to list the functions to be forgotten, it will
forget some (by following a buggy how-to -- which are all over the
Internet btw)
> Obviously this wouldn't protect against PHP bugs
> allowing arbitrary code execution, so it only
> mitigates the potential risk.
I'm sorry, but it's not an option to me. There security checks at kernel
level which must not be gotten arround by code running from userland
(PHP core).
Previous Comments:
[2010-11-12 01:28:55] luca at fantacast dot it
Just a thought on the dynamic setuid/setgid/chroot via fastcgi variables
exclusion because of security concerns.
In the group discussion you pointed out how this opens up the
possibility for an attacker to call posix_setuid/posix_setgid in PHP
code to get root privileges.
However this could be easily prevented by using disable_functions to
prevent these and other potentially harmful functions from being called
(system, exec, etc) which could be used to achieve the same goal and are
not desirable in a shared hosting environment anyway.
I guess this and other protections could be even enforced automatically
by PHP FPM if dynamic setuid/setgid/chroot via fastcgi variables is
requested.
Obviously this wouldn't protect against PHP bugs allowing arbitrary code
execution, so it only mitigates the potential risk.
[2010-09-25 18:26:58] mplomer at gmx dot de
Released patch v6 - Updated patch to be compatible with current PHP_5_3
branch (rev 303365)
There are no functional changes against v5
Merged (removed) parts which have already been committed:
- rev 301886: only one process (for all pools) could be killed by the
'dynamic' process manager
- rev 301912: Changed listen.backlog in the FPM configuration file to
default to 128 instead of -1
- rev 301913: Add libevent version to the startup debug log in FPM
- rev 301925: add 'max children reached' to the FPM status page
Changes:
- Undo change in config.m4 which has IMHO nothing to do with this patch
- Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and
5.3-branch is currently out of sync here!)
- (small code beautify)
--------
[2010-09-13 06:27:20] f...@php.net
You should "make clean" before recompiling with v5 patch.
The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3
branch.
++ Jerome
[2010-09-13 03:30:56] dennisml at conversis dot de
Is v5 of the patch known not to work with fpm in php 5.3.3? When
applying the patch I get the following segfault:
Program received signal SIGSEGV, Segmentation fault.
0x005cf319 in fpm_env_conf_wp (wp=)
at /home/dennis/php-5.3.3/sapi/fpm/fpm/fpm_env.c:141
141 if (*kv->value == '$') {
[2010-09-05 20:42:56] f...@php.net
@dennisml at conversis dot de
It's complex to do and security risky. Don't want to mess with that.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Patch added by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v9.patch Revision: 1289779853 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v9.patch&revision=1289779853 Previous Comments: [2010-11-11 18:17:12] f...@php.net I can't create a specific patch for 5.3.3. If you really want to test on 5.3.3, you can do: tar -xzvf php-5.3.3.tar.gz cd php-5.3.3 rm -rf sapi/fpm wget http://snaps.php.net/php5.3-20101530.tar.gz tar -xzvf php5.3-20101530.tar.gz mv php5.3-20101530/sapi/fpm sapi/fpm rm -rf php5.3-20101530 patch -p0 < fpm-nomorelibevent.v8.patch ./buildconf --force ./configure --enable-fpm --other-configure-args make && make install it should work and you have php 5.3.3 core and up to date and patched FPM. [2010-10-22 08:23:54] info at hninsider dot com Can we have the patch working with the current 5.3.3 production version. Dev snapshots are not for production use and v8 patch does not apply cleanly to latest production version. Please provide a working patch for latest 5.3.3 ( not dev ) production version. Thank you. ---- [2010-10-11 14:53:59] f...@php.net no problem tony :) [2010-10-11 14:40:40] tony2...@php.net I'd appreciate if you give me some time to test it in my environment. A week or so would be enough, I guess. ---- [2010-10-09 14:43:20] f...@php.net small bug correction. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1 ID: 52501 Comment by: f...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: Here is the v9 version of the patch. Nothing changes despite the fact that it applies on current svn revision (305343). Previous Comments: [2010-11-15 01:10:53] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v9.patch Revision: 1289779853 URL: http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v9.patch&revision=1289779853 [2010-11-11 18:17:12] f...@php.net I can't create a specific patch for 5.3.3. If you really want to test on 5.3.3, you can do: tar -xzvf php-5.3.3.tar.gz cd php-5.3.3 rm -rf sapi/fpm wget http://snaps.php.net/php5.3-20101530.tar.gz tar -xzvf php5.3-20101530.tar.gz mv php5.3-20101530/sapi/fpm sapi/fpm rm -rf php5.3-20101530 patch -p0 < fpm-nomorelibevent.v8.patch ./buildconf --force ./configure --enable-fpm --other-configure-args make && make install it should work and you have php 5.3.3 core and up to date and patched FPM. [2010-10-22 08:23:54] info at hninsider dot com Can we have the patch working with the current 5.3.3 production version. Dev snapshots are not for production use and v8 patch does not apply cleanly to latest production version. Please provide a working patch for latest 5.3.3 ( not dev ) production version. Thank you. ---- [2010-10-11 14:53:59] f...@php.net no problem tony :) [2010-10-11 14:40:40] tony2...@php.net I'd appreciate if you give me some time to test it in my environment. A week or so would be enough, I guess. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N New Comment: if you use the latest version, you should be able to run php-fpm -tt and post the result here. Previous Comments: [2010-11-15 11:10:22] paulgao at yeah dot net [r...@php_5_3]# svn up Updated to revision 305368. I use lastest revision. :-( [2010-11-15 10:40:05] f...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Can you please test the last SVN version (which has the -tt support) and report back to me. thx ++ jerome [2010-11-15 10:28:52] paulgao at yeah dot net I use --tt, but not output content. [2010-11-15 10:27:11] paulgao at yeah dot net backtrace: (gdb) bt #0 _zend_mm_free_int (heap=0x105ef810, p=0x7fff1fdf2bbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006b9fff in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3b9c in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b968b in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1728) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be0de in main (argc=3, argv=0x7fff1fdf27e8) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-15 10:06:38] f...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I need a backtrace and the FPM configuration file (/usr/local/etc/php-fpm.conf -- or a dump of the conf file you can get with 'php-fpm -tt') ++ Jerome The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N New Comment: hum it's weird. Can you recompile PHP starting with "make clean" ? If 'php-fpm -tt' does not work, can you execute the following command strace -s1024 -o/tmp/strace.fpm ./sapi/fpm/php-fpm -tt and post somewhere the file /tmp/strace.fpm or its content. thx Previous Comments: [2010-11-15 16:00:51] paulgao at yeah dot net ; ; FPM Configuration ; ; ; All relative paths in this configuration file are relative to PHP's install ; prefix. ; Include one or more files. If glob(3) exists, it is used to include a bunch of ; files from a glob(3) pattern. This directive can be used everywhere in the ; file. ;inclu...@expanded_sysconfdir@/fpm.d/*.conf ;; ; Global Options ; ;; [global] ; Pid file ; Default Value: none ;pid = @EXPANDED_LOCALSTATEDIR@/run/php-fpm.pid pid = /home/php-fpm.pid ; Error log file ; Default Value: @EXPANDED_LOCALSTATEDIR@/log/php-fpm.log ;error_log = @EXPANDED_LOCALSTATEDIR@/log/php-fpm.log error_log = /home/logs/fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug ; Default Value: notice ;log_level = notice log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 ;emergency_restart_threshold = 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 ;emergency_restart_interval = 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 ;process_control_timeout = 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes ;daemonize = yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 0.0.0.0:8001 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 ;listen.backlog = -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = @php_fpm_user@ ;listen.group = @php_fpm_group@ ;listen.mode = 0666 listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = nobody group = nobody ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixe
Bug #53311 [PATCH]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Patch added by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 Previous Comments: [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... ---- [2010-11-16 01:50:53] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v1.patch Revision: 1289868651 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v1.patch&revision=1289868651 ---- [2010-11-16 01:42:21] f...@php.net Can you look in the fpm error log ? (%prefix%/var/log/php-fpm.log if you didn't change the default value) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53311 -- Edit
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx Previous Comments: [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... ---- [2010-11-16 01:50:53] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v1.patch Revision: 1289868651 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v1.patch&revision=1289868651 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: can you: 1- stop FPM 2- remove or move /home/logs/fpm.log 3- set log level to DEBUG 4- run FPM 5- dump the content of /home/logs/fpm.log here thx Previous Comments: [2010-11-16 09:05:46] f...@php.net Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful [2010-11-16 03:21:51] paulgao at yeah dot net I patched, -tt is work, but startup failed, core dumped. (gdb) bt #0 _zend_mm_free_int (heap=0x18a01810, p=0x7fff93d7dbbe) at /root/PHP53/Zend/zend_alloc.c:2018 #1 0x006ba01f in fpm_cleanups_run (type=2) at /root/PHP53/sapi/fpm/fpm/fpm_cleanup.c:46 #2 0x006c3bcc in fpm_unix_init_main () at /root/PHP53/sapi/fpm/fpm/fpm_unix.c:232 #3 0x006b96ab in fpm_init (argc=, argv=, config=, prefix=, test_conf=0, base=0xda1748) at /root/PHP53/sapi/fpm/fpm/fpm.c:33 #4 0x006be10e in main (argc=3, argv=0x7fff93d7d658) at /root/PHP53/sapi/fpm/fpm/fpm_main.c:1783 [2010-11-16 01:52:26] f...@php.net Can you try the attached patch and try again please ? don't forget to run ./buildconf && ./configure ... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: with which user do you run FPM ? Try to set daemonize = off in php-fpm.conf and run it again. Previous Comments: [2010-11-16 09:23:02] paulgao at yeah dot net I use patch V2. if old fpm.log not remove, startup still failed. but old fpm.log removed, startup is OK. restart is OK too. what problem? [2010-11-16 09:17:44] f...@php.net can you: 1- stop FPM 2- remove or move /home/logs/fpm.log 3- set log level to DEBUG 4- run FPM 5- dump the content of /home/logs/fpm.log here thx [2010-11-16 09:05:46] f...@php.net Please use fpm-zlog_set_fd.v2.patch instead of fpm-zlog_set_fd.v1.patch. thx [2010-11-16 09:05:19] f...@php.net The following patch has been added/updated: Patch Name: fpm-zlog_set_fd.v2.patch Revision: 1289894719 URL: http://bugs.php.net/patch-display.php?bug=53311&patch=fpm-zlog_set_fd.v2.patch&revision=1289894719 [2010-11-16 03:24:22] paulgao at yeah dot net -tt output: Nov 16 10:23:42.631153 [NOTICE] [General] Nov 16 10:23:42.631199 [NOTICE] pid = /home/php-fpm.pid Nov 16 10:23:42.631205 [NOTICE] daemonize = yes Nov 16 10:23:42.631232 [NOTICE] error_log = /home/logs/fpm.log Nov 16 10:23:42.631239 [NOTICE] log_level = NOTICE Nov 16 10:23:42.631244 [NOTICE] process_control_timeout = 5s Nov 16 10:23:42.631250 [NOTICE] emergency_restart_interval = 60s Nov 16 10:23:42.631256 [NOTICE] emergency_restart_threshold = 10 Nov 16 10:23:42.631268 [NOTICE] Nov 16 10:23:42.631283 [NOTICE] [www] Nov 16 10:23:42.631288 [NOTICE] prefix = undefined Nov 16 10:23:42.631294 [NOTICE] user = nobody Nov 16 10:23:42.631303 [NOTICE] group = nobody Nov 16 10:23:42.631308 [NOTICE] chroot = Nov 16 10:23:42.631323 [NOTICE] chdir = Nov 16 10:23:42.631329 [NOTICE] listen = 0.0.0.0:8001 Nov 16 10:23:42.631334 [NOTICE] listen.backlog = -1 Nov 16 10:23:42.631340 [NOTICE] listen.owner = undefined Nov 16 10:23:42.631352 [NOTICE] listen.group = undefined Nov 16 10:23:42.631359 [NOTICE] listen.mode = 0666 Nov 16 10:23:42.631364 [NOTICE] listen.allowed_clients = undefined Nov 16 10:23:42.631370 [NOTICE] pm = dynamic Nov 16 10:23:42.631375 [NOTICE] pm.max_children = 48 Nov 16 10:23:42.631381 [NOTICE] pm.max_requests = 0 Nov 16 10:23:42.631391 [NOTICE] pm.start_servers = 16 Nov 16 10:23:42.631405 [NOTICE] pm.min_spare_servers = 16 Nov 16 10:23:42.631411 [NOTICE] pm.max_spare_servers = 32 Nov 16 10:23:42.631417 [NOTICE] pm.status_path = /fpm_status Nov 16 10:23:42.631423 [NOTICE] ping.path = /fpm_ping Nov 16 10:23:42.631428 [NOTICE] ping.response = pong Nov 16 10:23:42.631452 [NOTICE] catch_workers_output = yes Nov 16 10:23:42.631458 [NOTICE] request_terminate_timeout = 0s Nov 16 10:23:42.631464 [NOTICE] request_slowlog_timeout = 1s Nov 16 10:23:42.631478 [NOTICE] slowlog = /home/logs/fpm_slow.log Nov 16 10:23:42.631484 [NOTICE] rlimit_files = 51200 Nov 16 10:23:42.631489 [NOTICE] rlimit_core = 0 Nov 16 10:23:42.631495 [NOTICE] Nov 16 10:23:42.631515 [NOTICE] configuration file /home/codebase/server-config/php-fpm-api-test.ini test is successful The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53311 -- Edit this bug report at http://bugs.php.net/bug.php?id=53311&edit=1
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Comment by: f...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with this version of GCC FPM is not able to be
compiled,
there is a bug in FPM. We'll take care of it.
It this a reasonable solution ?
Previous Comments:
[2010-11-16 23:52:42] stefan at whocares dot de
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
--------
[2010-11-16 23:05:04] f...@php.net
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
--------
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
[2010-11-16 19:48:36] sriram dot natarajan at gmail dot com
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org2009-12-14 09:18:53.0 +
+++ fpm_atomic.h2010-11-15 01:50:31.0 +
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_tatomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_tatomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Comment by: f...@php.net
Reported by:stefan at whocares dot de
Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package:FPM related
Operating System: Linux (Debian for Sparc)
PHP Version:5.3.3
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
@stefan at whocares dot de
Did you run your patch on a ReadyNAS box ? If you test it and tell us it
works,
there is not reason not to integrate it. As far as I know, it's not been
tested
but for compilation only.
We don't want to leave someone behind, but as pierre told you there is
priorities.
We'll be glad if you help us.
Previous Comments:
[2010-11-17 01:16:15] paj...@php.net
and I was wiling to write arch, not OS
[2010-11-17 01:15:26] paj...@php.net
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
[2010-11-17 01:09:51] stefan at whocares dot de
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.
Req #53310 [Com]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1 ID: 53310 Comment by: f...@php.net Reported by:stefan at whocares dot de Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work on v8 Status: Wont fix Type: Feature/Change Request Package:FPM related Operating System: Linux (Debian for Sparc) PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: one simple test is to make php core the less as possible. You can create a file test.php wich does nothing but an "echo". Then you stress this page with FPM with ab (ab -c 100 -n 1 http://ip:port/test.php While the test is running you check the status page and see how it's goin' on. it should be a good primary test. Previous Comments: [2010-11-17 02:19:15] stefan at whocares dot de First of all: thanks for not taking my rant badly :) Of course I can run this code and, well "test" it. I would have been happier however if someone besides me had looked over the code and said "yes, that looks like it could work" ;) Right now it *is* running on two ReadyNAS (Sparc) boxes as well as on my SunFire 280R. It doesn't segfault which to me is a good sign and it's producing normale output from the small test scripts I have run. Haven't done extensive testing so far but will try running Wordpress and Drupal in the next couple of days. If there's any special test you'd like to see me run against the patched version of PHP, let me know. -------- [2010-11-17 01:18:49] f...@php.net @stefan at whocares dot de Did you run your patch on a ReadyNAS box ? If you test it and tell us it works, there is not reason not to integrate it. As far as I know, it's not been tested but for compilation only. We don't want to leave someone behind, but as pierre told you there is priorities. We'll be glad if you help us. [2010-11-17 01:16:15] paj...@php.net and I was wiling to write arch, not OS [2010-11-17 01:15:26] paj...@php.net It was not badly meant, only trying to show you alternative. I can't know nor judge the reason why you need v8 support, but have been there many times in the past for my numerous projects. We have to make decisions about which platforms we can support, and also which we stop to support. There is nothing personal or aggressive in our replies, only trying to explain the status and the reasoning behind it. Sorry if you took it so badly, that's not the aim of our comments, or mines in particular. [2010-11-17 01:09:51] stefan at whocares dot de @paj...@php.net Did it ever occur to you that I found this bug/problem because I *specifically wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd have certainly done so. Seeing that there already was a solution for Sparc v9 I thought there might be interest in a solution that would allow PHP to run on older machines. Hardware that maybe you're laughing about. But hardware that's still in fairly wide use. And, come to think of it, hardware that may also be the only hardware people in poorer countries than the one you're obviously living in are able to get their hands on. So I first asked and then got my hands dirty and even provided a possible solution - and one that could be easily implemented, too. And what for? Only to get ignorance and witty remarks in return. Well, I almost forgot that the PHP project has such a bad reputation when it comes to bugs and patches. Thanks for reminding me why. Now you can safely go back to your ivory tower and think about supporting next decade's hardware only. For my part, I promise to keep any bugs/problems in PHP I may find in the future to myself and will do the same for any patches I may come up with. Btw: the boxes I'm talking about are running Linux (which you could have seen by looking at the "OS:" tag) and I really have no idea why you'd call that a "soon to be dead OS". If you have a problem understanding the difference between a CPU and an OS, may I ask what exactly makes you think you can give some valuable input here? As for the "cruelly needed developers" you mention: I don't see why you should need those as long as the community comes up with patches you could use. Ok, if you keep driving away people like this, I start to have an idea as to why ;)
Bug #53311 [Com]: startup failed.
Edit report at http://bugs.php.net/bug.php?id=53311&edit=1 ID: 53311 Comment by: f...@php.net Reported by:paulgao at yeah dot net Summary:startup failed. Status: Feedback Type: Bug Package:FPM related Operating System: Centos 64-bit 5.5 PHP Version:5.3SVN-2010-11-15 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: with which user do you launch FPM ? Previous Comments: [2010-11-17 02:52:24] paulgao at yeah dot net I change log level = debug, and daemonize = off: [r...@host-c11 logs]# /home/codebase/shell/php-fpm-api-test.sh start Starting php-fpm Nov 17 09:49:46.600069 [DEBUG] pid 24660, fpm_event_init_main(), line 93: libevent 1.4.14b-stable: using epoll Nov 17 09:49:46.600466 [NOTICE] pid 24660, fpm_init(), line 52: fpm is running, pid 24660 Nov 17 09:49:46.602313 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24661 started Nov 17 09:49:46.603101 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24662 started Nov 17 09:49:46.605003 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24664 started Nov 17 09:49:46.606135 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24665 started Nov 17 09:49:46.607143 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24666 started Nov 17 09:49:46.608088 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24667 started Nov 17 09:49:46.609757 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24669 started Nov 17 09:49:46.610090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24670 started Nov 17 09:49:46.611090 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24671 started Nov 17 09:49:46.612089 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24673 started Nov 17 09:49:46.613112 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24674 started Nov 17 09:49:46.614087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24676 started Nov 17 09:49:46.615136 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24677 started Nov 17 09:49:46.616087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24679 started Nov 17 09:49:46.617097 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24680 started Nov 17 09:49:46.618087 [DEBUG] pid 24660, fpm_children_make(), line 403: [pool www] child 24682 started Nov 17 09:49:46.618121 [NOTICE] pid 24660, fpm_event_loop(), line 111: ready to handle connections Nov 17 09:49:46.618155 [DEBUG] pid 24660, fpm_got_signal(), line 48: received SIGCHLD Nov 17 09:49:46.618203 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24661 exited with code 1 after 0.015918 seconds from start Nov 17 09:49:46.619091 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24683 started Nov 17 09:49:46.619126 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24662 exited with code 1 after 0.016037 seconds from start Nov 17 09:49:46.620113 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24685 started Nov 17 09:49:46.620147 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24664 exited with code 1 after 0.015152 seconds from start Nov 17 09:49:46.621129 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24686 started Nov 17 09:49:46.621170 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24665 exited with code 1 after 0.015041 seconds from start Nov 17 09:49:46.622087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24688 started Nov 17 09:49:46.622120 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24666 exited with code 1 after 0.014983 seconds from start Nov 17 09:49:46.623089 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24689 started Nov 17 09:49:46.623121 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24667 exited with code 1 after 0.015042 seconds from start Nov 17 09:49:46.624087 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24691 started Nov 17 09:49:46.624123 [WARNING] pid 24660, fpm_children_bury(), line 249: [pool www] child 24669 exited with code 1 after 0.014373 seconds from start Nov 17 09:49:46.625096 [NOTICE] pid 24660, fpm_children_make(), line 403: [pool www] child 24692 started non-stop output... :-( [2010-11-16 22:26:37] f...@php.net with which user do you run FPM ? Try to set daemonize = off in php-fpm.conf and run it again. [2010-11-16 09:23:02] paulgao at
