[PHP-DEV] Re: [PHP-CVS] com php-src: FPM: change "listen = port" behavior from IPv4 catch-all to IPv6 catch-all (+ IPv4-mapped): UPGRADING sapi/fpm/fpm/fpm_sockets.c sapi/fpm/php-fpm.conf.in
Hello Remi.
I do understand that I'm a bit late with this one, but this patch actually
FORCES IPv6 for port-only syntax.
I've got both IPv6 and IPv4 configured and getaddrinfo() returns only 1 address
- the IPv6 one.
This happens because "::" seems to be a shorthand for "::1".
So when no hostname is specified FPM always tries to listen on IPv6 only
instead of doing what the patch was intended to do.
The only way to force IPv4 is to specify IP address or a hostname ("localhost"
is enough).
This either needs to be fixed, or reflected in the docs.
Here's to demonstrate it:
288 if ((status = getaddrinfo(addr, port_str, , ))
!= 0) {
(gdb)
294 for (p = servinfo; p != NULL; p = p->ai_next) {
(gdb) p *servinfo
$4 = {ai_flags = 0, ai_family = 10, ai_socktype = 1, ai_protocol = 6, ai_addrlen =
28, ai_addr = 0xbdb3c0, ai_canonname = 0x0, ai_next = 0x0} < NO ai_next, so
it's the only option.
(gdb) p addr
$5 = 0x8ace8c "::"
On 11/24/2014 08:38 AM, Remi Collet wrote:
Commit:95a609c5d14a2c5295886065a24db8344844ca8b
Author:Remi Collet <r...@php.net> Mon, 24 Nov 2014 09:38:36 +0100
Parents: d8fbcca725264cbca3ea88375bfb7879f81175d7
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=95a609c5d14a2c5295886065a24db8344844ca8b
Log:
FPM: change "listen = port" behavior from IPv4 catch-all to IPv6 catch-all (+
IPv4-mapped)
Changed paths:
M UPGRADING
M sapi/fpm/fpm/fpm_sockets.c
M sapi/fpm/php-fpm.conf.in
Diff:
diff --git a/UPGRADING b/UPGRADING
index fe28213..9d5d8e7 100644
--- a/UPGRADING
+++ b/UPGRADING
@@ -63,6 +63,7 @@ PHP X.Y UPGRADE NOTES
- FPM
. Fixed bug #65933 (Cannot specify config lines longer than 1024 bytes).
+ . Listen = port now listen on all addresses (IPv6 and IPv4-mapped).
4. Deprecated Functionality
diff --git a/sapi/fpm/fpm/fpm_sockets.c b/sapi/fpm/fpm/fpm_sockets.c
index 0286f0e..e4e4948 100644
--- a/sapi/fpm/fpm/fpm_sockets.c
+++ b/sapi/fpm/fpm/fpm_sockets.c
@@ -268,6 +268,8 @@ static int fpm_socket_af_inet_listening_socket(struct
fpm_worker_pool_s *wp) /*
} else if (strlen(dup_address) == strspn(dup_address, "0123456789")) {
/* this is port */
port = atoi(dup_address);
port_str = dup_address;
+ /* IPv6 catch-all + IPv4-mapped */
+ addr = "::";
}
if (port == 0) {
@@ -275,18 +277,6 @@ static int fpm_socket_af_inet_listening_socket(struct
fpm_worker_pool_s *wp) /*
return -1;
}
- if (!addr) {
- /* no address: default documented behavior, all IPv4 addresses
*/
- struct sockaddr_in sa_in;
-
- memset(_in, 0, sizeof(sa_in));
- sa_in.sin_family = AF_INET;
- sa_in.sin_port = htons(port);
- sa_in.sin_addr.s_addr = htonl(INADDR_ANY);
- free(dup_address);
- return fpm_sockets_get_listening_socket(wp, (struct sockaddr *)
_in, sizeof(struct sockaddr_in));
- }
-
/* strip brackets from address for getaddrinfo */
addr_len = strlen(addr);
if (addr[0] == '[' && addr[addr_len - 1] == ']') {
@@ -307,10 +297,10 @@ static int fpm_socket_af_inet_listening_socket(struct
fpm_worker_pool_s *wp) /*
inet_ntop(p->ai_family, fpm_get_in_addr(p->ai_addr), tmpbuf,
INET6_ADDRSTRLEN);
if (sock < 0) {
if ((sock = fpm_sockets_get_listening_socket(wp,
p->ai_addr, p->ai_addrlen)) != -1) {
- zlog(ZLOG_DEBUG, "Found address for %s, socket
opened on %s", dup_address, tmpbuf);
+ zlog(ZLOG_DEBUG, "Found address for %s, socket
opened on %s", addr, tmpbuf);
}
} else {
- zlog(ZLOG_WARNING, "Found multiple addresses for %s, %s
ignored", dup_address, tmpbuf);
+ zlog(ZLOG_WARNING, "Found multiple addresses for %s, %s
ignored", addr, tmpbuf);
}
}
diff --git a/sapi/fpm/php-fpm.conf.in b/sapi/fpm/php-fpm.conf.in
index b2d8a22..850a369 100644
--- a/sapi/fpm/php-fpm.conf.in
+++ b/sapi/fpm/php-fpm.conf.in
@@ -155,9 +155,7 @@ group = @php_fpm_group@
;a specific port;
; '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6
address on
;a specific port;
-; 'port' - to listen on a TCP socket to all IPv4 addresses
on a
-;specific port;
-; '[::]:port'- to listen on a TCP socket to all addresses
+; 'port' - to listen on a TCP socket to all addresses
;(IPv6 and IPv4-mapped) on a specific po
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On 2013-05-12 19:25, Nikita Popov wrote: Hi internals! https://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. IMO the proposal B is quite reasonable change, but the proposal A (i.e. the operator overloading part) is definitely an overkill. A simple benchmark should demonstrate that using GMP for basic arithmetic would kill performance in quite a brutal way. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 2012-11-12 17:00, Adam Harvey wrote: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only. Generating 'educational' notices will just annoy the end users and in 99% cases they can't do a thing about it - nobody's going to rewrite a large piece of legacy software just to make PHP happy. More notices doesn't necessarily mean less people are going to use ext/mysql, you can't hasten users to move if they don't really want to do it themselves. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 2012-11-12 18:15, Adam Harvey wrote: I don't think the documentation is necessarily effective here, particularly with functions that users tend to know by heart skip I'm not really convinced the average user ever looks at the manual for things they know, truth be told. Well, I'd expect people actively developing applications in PHP to use the docs from time to time. But my concern is for people using legacy apps. True, they might not use the docs at all and the only warning they'll get when they do their usual PHP upgrade is error logs stuffed full of E_DEPRECATED. So what is they going to do in that case? Disable the notice, of course. Just a random thought: is it possible to 'emulate' ext/mysql funcs using, say, ext/mysqli, similar to how ext/mhash functions are now emulated by ext/hash? -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recycle PHP Log
Just use logrotate for that. On 2012-10-25 23:16, Raymond Irving wrote: Hello, How about adding an option to recycle the PHP log when it gets too big? For example: [php ini] max_error_log_size = 512k When the log file is larger than 512k rename the file by adding the current date or timestamp: php_error_as_at_2012_10_10.log __ Raymond -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 2012-07-03 20:49, Arvids Godjuks wrote: One one side it's good to know i'm not wrong, on the other hand it's sad in this case. Sure about one thing - xcache is worth looking at and may be a better choise than APC and has better potential. One thing sure - I haven't heard anyone complaining about xcache. And heard many complains about APC. XCache just crashed for me: http://xcache.lighttpd.net/ticket/240 No reproduce case and no idea how to make one - there are megabytes of code involved. We've been using APC for a year and a half after that and I was pretty much happy with it, except it crashed ~once a day with totally obscure backtrace. Not much of a problem, but kind of annoying and APC sources gave me headaches, so I revived eAccelerator instead and made it work with 5.3. With EA there was absolutely no difference in performance comparing to APC and the crashes are gone now. But now I'll have to make EA work with 5.4 and it's interned string hell.., which is quite different story. You might want to look at my EA fork, though: https://github.com/tony2001/eaccelerator/tree/alt -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ECDSA support in the openssl extension
On 03/21/2012 02:34 AM, Sergey Ryazanov wrote: After some time of digging I discover that this error is rises in the php_openssl_is_private_key() in the openssl.c file. This function simply don't includes check for EVP_PKEY_EC. All signature related actions are performed by OpenSSL library by self and don't depend on any internal code. Is any chance that EVP_PKEY_EC check would be added in the next release? Could I do something to speed up ECDSA adding process? Yes! You can always provide a patch and attach it to the bug report =) -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP-FPM and max_execution_time
On 03/07/2012 03:47 PM, Christian Kaps wrote: The Apache logs prints: FastCGI: comm with server /home/christian.kaps/fcgi.sock aborted: idle timeout (30 sec) FastCGI: incomplete headers (0 bytes) received from server /home/christian.kaps/fcgi.sock http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidiotimeout ? The error in the *Apache* logs kinda means the Apache has hit a timeout, not PHP. offtopicUgh.. nice anchor/directive name, Apache guys./offtopic -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4RC4 does not compile
On 01/06/2012 09:06 PM, Steven VAN POECK wrote: I may be doing this wrong, but on a fresh Debian 6.03 install on a VMWare VM (VMWare tools installed, build-essential installed), the php5.4 rc4 tarball from snaps.php.net (php5.4-201201041830.tar.gz) does not compile. Can you still reproduce it with RC5? I can't see any problems here both with and without bison installed (which is used to generate this file from zend_ini_parser.y). -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 52062
On 12/26/2011 12:40 PM, Derick Rethans wrote: I'll have a look when I get back home. Is there anything else you want me to look at? Yes! https://bugs.php.net/bug.php?id=53437 =) -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for updating zbacktrace in gdbinit
On 12/06/2011 10:33 AM, Laruence wrote: Hi: I am plan to commit a new change to 5.4-trunk/.gdbinit which can be found at http://pastebin.com/N6hTRMRA. Looks nice, please commit it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] export zend_on_timeout()
Hello all. I'd like to commit a one-liner to 5_4/trunk if there are no objections. See it in the attachment. Stas, do you mind if I commit it to 5_4 now? -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP Index: Zend/zend.h === --- Zend/zend.h (revision 319511) +++ Zend/zend.h (working copy) @@ -683,7 +683,7 @@ #endif extern ZEND_API void (*zend_ticks_function)(int ticks); extern ZEND_API void (*zend_error_cb)(int type, const char *error_filename, const uint error_lineno, const char *format, va_list args) ZEND_ATTRIBUTE_PTR_FORMAT(printf, 4, 0); -extern void (*zend_on_timeout)(int seconds TSRMLS_DC); +extern ZEND_API void (*zend_on_timeout)(int seconds TSRMLS_DC); extern ZEND_API int (*zend_stream_open_function)(const char *filename, zend_file_handle *handle TSRMLS_DC); extern int (*zend_vspprintf)(char **pbuf, size_t max_len, const char *format, va_list ap); extern ZEND_API char *(*zend_getenv)(char *name, size_t name_len TSRMLS_DC); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI + Valgrind = FAIL
On 11/08/2011 10:43 AM, Rasmus Lerdorf wrote: Indeed, valgrind says: ==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction(); ==47112== the SIGUSR2 signal is used internally by Valgrind So it looks like it won't allow PHP to override signal handlers. The questions here are - does anybody sees same problem (on Mac or other systems) and should PHP really fail in this scenario? Not having the possibility to run PHP under valgrind kind of sucks. Yeah, definitely looks like some Valgrind + OSX problem. I use Valgrind with PHP for years on Linux 32bit/64bit and it works just perfectly. Mine is 3.6.1, too. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend memory managment null pointer dereference
On 10/03/2011 11:42 PM, Chester, Alan wrote: Hi, I have recently seen httpd core dump on my system. After looking into this issue it is the php module which is actually core dumping more specifically the zend memory management part of php. #0 0x0115d224 in zend_mm_remove_from_free_list (heap=0x99596e8, p=value optimized out) at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:837 This is the worst kind of segfault since GDB backtrace doesn't carry any useful information in this case, it just tells us that the crash has happened at the request shutdown. But the real problem that caused the crash has occurred somewhere during the request and there's no way to know when where basing on the backtrace only. I'd suggest to try reproducing this problem with Valgrind: https://bugs.php.net/bugs-getting-valgrind-log.php, this would give us a lot more info. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend memory managment null pointer dereference
On 10/04/2011 12:06 AM, Chester, Alan wrote: Antony, Thank you for the quick response. I will work towards finding a reproducer and using valgrind to gather more information. Since I have been trying for to find a reproducer but have had no luck so far, do you think reducing the cache size would help in finding a reproducer? If so how is this done? Or does cache/cache size have nothing to do with this area of code? Reducing the cache size will not help for sure, but disabling the cache entirely will help us to understand whether this problem is caused by your cache or not. Btw, you didn't specify which kind of cache is that. Also would you like to me open a bug ticket to track this issue? It depends on the kind of cache you're using (there are several caches on the market that aren't part of PHP project) and whether the cache is guilty or not. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] open_basedir bypass - errata tempnam()
On 09/28/2011 02:39 AM, Reindl Harald wrote: PLEASE REPLY ONLY TO THE LIST Please provide a short (10 lines max) but complete reproduce script. At the moment your explanations do not make any sense. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On 08/04/2011 04:39 PM, Lazare Inepologlou wrote: ... ( $x ) = $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability. ... people wanted an easy way to grep for function declarations A new and unique operator (like the |= I have proposed) is a solution that works because: Please stop that, it's not funny anymore. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On 08/04/2011 05:04 PM, Derick Rethans wrote: On Thu, 4 Aug 2011, Victor Bolshov wrote: Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? No. I don't see at all why we need this, just like I don't see why we needed an alternative (short) syntax for arrays. This kind of syntax additions that add *no* functionality, should not be in PHP. Yes, I believe we should stop this stream of alternative syntax proposals and concentrate on fixing existing functionality instead of adding less readable ways to do the same thing. I would really like to keep PHP code easily readable, not to turn it into perl-ish write-only gibberish. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Big patch for FPM (config and initialization)
On 07/03/2011 04:50 AM, Giovanni Giacobbi wrote: Detailed changelog of the patch: - Renamed options pm.status_path, ping.path, ping.response into a new logical group diagnostics, so they are now respectively: diagnostics.status_path, diagnostics.ping_path, diagnostics.ping_response. I'm not quite sure renaming config options would help anybody, in my opinion it would do more harm than good. I personally would certainly expect my existing config files to continue to work after upgrade to 5_4. Yes, we're changing '3' to '4' in the version number, but that doesn't mean we can just go ahead and break the config file. Other than that, looks ok to me (assuming you've tested it and does continue to work the way it worked before all those cosmetic changes). -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 06/01/2011 01:59 AM, Rasmus wrote: Other than a couple of grumpy old-timers, I think we are in agreement that we should add a short array syntax. Well, thanks for calling me that! =) But seriously, I don't think all of these people are grumpy old-timers: Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier (yeah, I know some of them have changed their votes already) -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 05/31/2011 10:42 PM, Brian Moon wrote: https://wiki.php.net/rfc/shortsyntaxforarrays I can has vote on this RFC https://wiki.php.net/rfc/shortsyntaxforfunctions ? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in zend_hash_init()
On 04/28/2011 02:53 PM, Anton Dobkin wrote: // No checking on return value? Yes, it doesn't check for NULL. See ecalloc() sources in Zend/zend_alloc.c around line 2434 to see why. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPUnit segfault
On 04/23/2011 02:43 AM, Andras Albert Gyomrey Leal wrote: Hi, I'm a bit lost here. Don't know where to go, since PHP 5.3.6 i'm getting random segfaults using PHPUnit. Xdebug disabledPHPUnit 3.5.13CentOS 5.1Linux 2.6.18-028stab070.5 #1 SMP Fri Sep 17 15:37:23 MSD 2010 i686 i686 i386 GNU/LinuxCentOS release 5.6 (Final)Apache 2.2.17 I just want to know if i'm on the right place and which tools may i use to debug this.By random segfaults i mean some times a testsuite completes without any trouble,and some other times it fails somwhere in the middle, See here: http://bugs.php.net/bugs-generating-backtrace.php -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend mm
On 01/28/2011 09:06 AM, Adi Mutu wrote: Hello, Nobody can help me understand better the internals of the zend memory manager? What's your question? Are there any books about zend_mm_aloc_int() and zend_mm_free_int(), structs like zend_mm_heap etc? No, the sources are your best source =) of information. If you have any exact questions, no need to ask if anybody can help you, just ask your questions right away. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fully enabling dl() for FPM SAPI
On 01/17/2011 09:19 PM, Johannes Schlüter wrote: I think it can be quite dangerous if you have extensions living shorter than the PHP process. Not only might dlclose() cause some leaks but there are a few extensions playing with function pointers or opcode handlers which aren't properly reset so a following request might try to jump to invalid memory. dlclose()? I can assure you I'm not going to call dlclose() on each request shutdown. Yes, that means once an extension is loaded it'll stay till the death of this particular child process). But it does work here for the last 5 or 6 years this way and this is indeed what I want. TBH I'm not even sure dlclose() is called at all since I wasn't able to track this call down through all the handlers, destructors and so on in 5 min I spent on this.. Additionally there's no restriction on this once safe_mode is gone, so anybody could load any C extension - while that can be fixed by advertising disable_function=dl That's right, disabling it is not a problem. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fully enabling dl() for FPM SAPI
Hi all! Are there any objections if I disable E_DEPRECATED notice in dl() for FPM SAPI? The notice is already disabled for CGI/FastCGI, CLI and Embed SAPIs. I believe there's no reason for this notice in case of FPM, too. Patch: http://dev.daylessday.org/diff/fpm_dl_notice.diff -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix memory leak in fpm_conf_set_array()
On 12/28/2010 01:50 AM, Cristian Rodríguez wrote:
- if (err) return err;
+ if (err) { free(kv); return err;}
I believe the patch is a bit more complicated than that.
Here is new version: http://dev.daylessday.org/diff/fpm_leaks.diff
Could you test it please?
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: lytboris
On 12/14/2010 10:10 PM, Boris Lytochkin wrote: Mantain ext/snmp extension: src docs Did somebody recommend you to apply for an account? (..and is ready to vouch for you?) Or did you start sending patches and have reached a moment when an account is really needed? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: lytboris
On 12/22/2010 06:09 PM, Larry Adams wrote: I support. He has one of the worlds largest cacti installs and I have reviewed and found the patch good. Which patch are you talking about? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-1
On 11/27/2010 08:40 PM, Johannes Schlüter wrote:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to prevent conflicts, I therefore propose the
following RFC incl. patch to allow writing
class Foo {
public bar() {
echo Hello World;
}
}
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
johannes
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
I really like Git (much more than SVN actually) and I use it for all my projects, but I doubt moving to Git would solve anything. IMO even CVS was quite enough for our development model. On 11/25/2010 04:47 AM, Pierre Joye wrote: hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Cheers, -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php gettext bindtextdomain behavior
On 11/05/2010 11:06 PM, Gerry Reno wrote: In PHP 5.2.4 (my version) the gettext bindtextdomain function is not returning the existing directory settings when the directory argument is NULL. That is the expected behavior for bindtextdomain with GNU and it works this way elsewhere such as in python. With PHP what happens is that is just returns the current directory rather than the existing bindtextdomain directory setting. PHP EXAMPLE: bindtextdomain(messages, ./locale); textdomain(messages); print bindtextdomain(messages,NULL).\n; print textdomain(NULL).\n; ACTUAL: (incorrect) # php test.php /var/www/htdocs messages EXPECTED: # php test.php ./locale messages Can PHP gettext bindtextdomain be fixed to correctly return the existing setting when called with a NULL directory argument? PHP of course just calls GNU textdomain() and you see the result the original function returns, not some PHP-specific result. And no, I cannot reproduce this with PHP 5.3.4-dev or PHP 5.2.15-dev. You might want to update your PHP and try again. If you're still able to reproduce it - make sure the problem doesn't appear to be in some distro-specific patch, i.e. get the original source tarball from php.net and check if the problem actually exists there. After that you're welcome to fill a bug-report. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zlib compile
On 10/21/2010 07:09 PM, lon...@gmail.com wrote: PHP 5.2.14 Docs say to compile w/ zlib you need to use the --with-zlib[=DIR] flag. This does not work. You need to use --with-zlib --with-zlib-dir=[DIR] No, you don't have to use it, --with-zlib works just fine: # ./configure --with-zlib=/no/zlib/there ... checking for OpenSSL support... no checking for Kerberos support... no checking for PCRE support... no checking for ZLIB support... yes checking if the location of ZLIB install directory is defined... no configure: error: Cannot find libz You can open ext/zlib/config0.m4 and check the logic behind both options. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with iconv on AIX 5.3 and 6.1 - maybe a bug
On 10/11/2010 10:35 PM, Michael Felt wrote: As to 5.3 - personally, I have some oldish PHP code that does not like some of the new defaults in 5.3 (as least when I tried when it first came out). However, I shall soon do 5.2.14. I'd still recommend at least _to try_ 5.3 just to make sure it really does compile work fine. If that is the case, you can start backporting AIX-related changes from 5.3 to 5.2. There is another AIX idiosycrancy I found. It does not like the BUILD_CLI string in the Makefile. If I edit it into seperate lines and put those where $(BUILD_CLI) stands, the sapi/cli/php program configures fine. Make sure you use GNU make and as much other GNU utils as possible - the native ones are broken. Fun in porting :) Well, I wouldn't call that fun.. it's more of a frustration to me. Off topic I know - but how much interest is there is a more explicit debug info of the BUILD_CLI issue. Personally I find it very strange as it used to work fine (the string does not look to have changed in a long time. I would guess it is some security 'improvement' in make or ksh. GNU bash and GNU make should certainly fix it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with iconv on AIX 5.3 and 6.1 - maybe a bug
On 10/10/2010 12:13 AM, Michael Felt wrote: I think it is a bug, but it might also be a misunderstanding. Background: I am trying to convert Joomla 1.0.X to 1.5.X and ran into problems with the conversion of the database that is done during the migration. I started out by doing several of the tests/samples in the php manuals, but always got blank results. I tried changing the php.ini settings: [iconv] iconv.input_encoding = ISO8859-1 iconv.internal_encoding = ISO8859-1 iconv.output_encoding = ISO8859-1 Well, yes, it's a known problem that AIX contains it's very own version of iconv. At least it differs from everything else I've seen so far (in terms of encoding names and functionality). #else REGISTER_STRING_CONSTANT(ICONV_IMPL, unknown, CONST_CS | CONST_PERSISTENT); #endif REGISTER_STRING_CONSTANT(ICONV_VERSION, version, CONST_CS | CONST_PERSISTENT); It seems my system is being configured, but under #else - unknown. Probably ibm might be better, but it doesn't change much.. I did some digging in configure. Once configures finds iconv (PHP version 5.2.13 line numbers!) You should look into ext/iconv/config.m4 instead. ./configure is generated and it's not supposed to be read. Also I'd suggest you to try 5.3 branch, I can see that AIX iconv support exists only there. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 06/20/2010 10:21 PM, Ilia Alshanetsky wrote: I for one think it is a really good idea, there is no compelling reason not to include APC, I would even go as far as say we should enable it by default. +1 on adding into the distro -1 on enabling by default -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 06/21/2010 04:32 PM, Jim Jagielski wrote: As a PHP user, when moving to PHP 5.3, from 5.2 I had the question regarding which accel to use (I had been using APC). From most of what I read, APC was not compatible and looking at the APC site, the last 'stable' release was ~2years ago with a bunch of betas. I then looked at XCache and saw that it was more maintained as well as explicitly mentioned PHP 5.3 compatibility. In other words, to the unwashed masses, XCache, for example, seemed a better and safer choice than APC, despite the list of names attached to the latter. We've been experiencing some troubles with APC + 5.3, too, so I tried switching to XCache and my experience is described here: http://xcache.lighttpd.net/ticket/240 Judging by XCache SVN, there were no changes since then. So we're still using APC + 5.3 in production, even though I get a core now and then (weird, last segfault was ~2 weeks ago..). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On 24.05.2010 21:54, Ilia Alshanetsky wrote: Denis, Could you merge the patches into a single for easier code review. Hint: `diff -u` produces a bit more human-readable patch. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Compilation of trunk with --enable-dtrace
On 06.05.2010 15:21, David Soria Parra wrote: FreeBSD Dtrace is known to be broken because of a syntax issue somewhere in their DTrace scripts that are included by default. FreeBSD dtrace is not supported at the moment. Anyway, you need to check the result of dtrace execution and abort with a nice errmsg if it fails. Also you might want to detect dtrace's version before running it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 10:58, Jérôme Loyet wrote: Le 26 avril 2010 04:02, looyao teng tly.phpf...@gmail.com a écrit : in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage) or VmSize(virtual memory usage) is the the memory usage of the current process. in fact I was looking of a cleaner way to do it. PECL/memtrack does it already. I still don't get why do you want to duplicate it in FPM? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 12:15, Jérôme Loyet wrote: 2010/4/26 Antony Dovgal t...@daylessday.org: On 26.04.2010 10:58, Jérôme Loyet wrote: Le 26 avril 2010 04:02, looyao teng tly.phpf...@gmail.com a écrit : in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage) or VmSize(virtual memory usage) is the the memory usage of the current process. in fact I was looking of a cleaner way to do it. PECL/memtrack does it already. I still don't get why do you want to duplicate it in FPM? I think the goal is not the same. PELC/memtrack produce a warning if memory is over the soft limit and stops execution if it's over the hard limit. You can always add another limit and another action. Moreover, it checks only the memory allocated by the Zend Stack. Nope. The goal here is to mesure memory usage after each request and kill the process if it's larger than the limit. We don't wan't to limit each process but we want to check it's been free'd correctly It's easy to do when checking the Zend Stack Size (ZSS ?) but it's not the same if you want to check also memory allocation which have bypassed the ZSS. That's why memtrack uses mallinfo(). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 13:38, Jérôme Loyet wrote: I see how adding limits but how can a PECL module can do process management (killing) without interfacing with the corresponding SAPI ? What exactly are you going to do? Killing a process is as easy as exit(), no interfacing is needed. That's why memtrack uses mallinfo(). mallinfo is not present on every system (mac os, *bsd, ...) Hah! I knew you'd say it. It works fine on FreeBSD 8.0. If there is some way to get this info on other systems, we can implement it in the extension. If there is no such info available - you can forget about those systems anyway, you can't help it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 14:08, Jérôme Loyet wrote: What exactly are you going to do? Killing a process is as easy as exit(), no interfacing is needed. and when threads are used ? You'll kill all threads at once without waiting them to finish what they're doing at the time ? Let's start from the beginning. How are you going to detect how much memory a thread consumes? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 18:02, Jille Timmermans wrote: memtrack could do the usual trick; stopping the current script or whatever. and FPM could flag the process as 'over the memory limit' and can kill it as soon as there are no other threads running in that process. There are no threads in FPM or FastCGI. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 19:20, looyao teng wrote: 2. The PHP's management of memory can't give the occupied memory back to the system by itself. This is simply not true. It does cache some blocks, but usually the memory is simply free()d. 3.Though the idea is good,it cannot acquiret the actual state of the memory usage of the process for PHP. Meanwhile,the other methods are not good enough in a way,such as cannot run on multi-platform.So we hope to try to monitor and manage the heap memory.After all,the used memory of PHP itself is relatively stationary.And the memory_limit is ought to limit the heap memory. So, when it go beyond the limit,kill the process in order to release the memory. What do you mean by the idea? Your initial idea? Other methods? Multi-platform? Yes, surely mallinfo() is not multiplatform. But it shows the real memory usage, not Zend MM stats. So what's your point? 4. I'm agree that it's not necessary to realize this feature in SAPI, but it may be not easy to realize in other pleaces, because it must check after current task execute, and SAPI is not all like FPM that is independent process existing. Erm.. Come again? 6. I do not install memtrack, according to the README, I think it's not my really want , the focus of my requirement is not to log or throw exception, because I know my problem is what, I need to solve it, and the solution is to exit. I repeat: you can add another limit to memtrack and another action. And this time it might be exit(), not warning. But after looking at your patch, I believe that this problem is NULL since the very beginning. You're checking Zend MM stats and that number is always 0 after request shutdown and before request startup, no matter what. If you have any problems with third-party libs leaking memory not accounted by Zend MM, you can always lower the max_requests parameter in your config file. That's all. Problem solved. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 22:25, Ferenc Kovacs wrote: If you have any problems with third-party libs leaking memory not accounted by Zend MM, you can always lower the max_requests parameter in your config file. That's all. Problem solved. Its not the best idea. If you feed imagick with random images, then your memory leak will be pretty random. Random actions end up with random results. Thank you, captain! If you set the max_requests low, then you will see fewer memory limit exhausted, but the overall overhead will be much bigger, because you will respawn a decent amount of worker unnecessary Respawn overhead is almost zero if you compare it to the overall cost of executing, say, 1000 of scripts. if you set it high, the overhead will be lower, but you will see much more aborted scripts. Aborted scripts? Since when do they abort when some third-party lib leaks some memory? With the ability, to respawn processes based on the memory allocation, you could serve the maximal amount of request, without unnecessary respawn or aborted scripts. My point was and is that with Zend MM enabled, it takes care of any leaks that might happen in PHP and they won't accumulate, as each time a request starts, we start with clean Zend MM pool. In order to prevent leaks happening in third party libraries (which Zend MM is unable to control) to blow up your PHP processes, you need to use the non-portable solution I implemented in memtrack, not the one proposed in the original patch. And even that is not required as you can always adjust max_requests and live happily ever after. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 26.04.2010 23:12, Ferenc Kovacs wrote: You are so kind. I'm so proud of you!! But sticking with a real world scenario: you have to convert what they upload, and thats pretty random. Yes. And there is no way to fix it. But that doesn't mean there MUST be any leaks at all. Btw, there are also other image libraries in this world. Not to mention that you can still use Imagemagick, but move the conversion from web to some CLI script. Respawn overhead is almost zero if you compare it to the overall cost of executing, say, 1000 of scripts. if you have to set the max_request to for example 10, because of the aborted scripts, then it is not zero We're talking about real life scenario here, please stick to it. if you set it high, the overhead will be lower, but you will see much more aborted scripts. Aborted scripts? Since when do they abort when some third-party lib leaks some memory? When the leaked memory causes a memory limit was exhausted fatal error? It doesn't - Zend MM nothing nothing about third party libs. My point was and is that with Zend MM enabled, it takes care of any leaks that might happen in PHP and they won't accumulate, as each time a request starts, we start with clean Zend MM pool. Yeah, but if you followed the thread, you can see that the external libs are the problem. RIGHT! That's exactly what I'm talking about! And the initial patch uses Zend MM to check the leaks, which is wrong. In order to prevent leaks happening in third party libraries (which Zend MM is unable to control) to blow up your PHP processes, you need to use the non-portable solution I implemented in memtrack, not the one proposed in the original patch. http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/getrusage.c?rev=1.18;content-type=text%2Fx-cvsweb-markup Yes? Did you notice the word 'memory' is not even present on that page? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging a PHP Extension via GDB
On 22.04.2010 17:51, Sebastian Kurfürst wrote: GDB then asks: No source file named /path/to/php/extension/objectmonitor/objectmonitor.c. Make breakpoint pending on future shared library load? (y or [n]) y When I run php with a script via run index.php, the system does not stop at the set break-point. Make sure the extension is loaded and it was compiled with debug symbols (-g3 helps a lot). You might also want to compile the extension statically, I personally find it much more convenient way to debug. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 06.04.2010 11:11, 滕路遥 wrote: So I suggest that if we could add a config option to PHP-FPM, so that PHP-FPM could just kill a PHP process if it consumes too much memory (say more than 256M). I personally don't think this belongs to any SAPI. How about adding another ini option to PECL/memtrack to not just throw a warning, but terminate the process when it hits some limit? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 15.04.2010 12:23, Jérôme Loyet wrote: 2010/4/15 Antony Dovgal t...@daylessday.org: On 06.04.2010 11:11, 滕路遥 wrote: So I suggest that if we could add a config option to PHP-FPM, so that PHP-FPM could just kill a PHP process if it consumes too much memory (say more than 256M). I personally don't think this belongs to any SAPI. How about adding another ini option to PECL/memtrack to not just throw a warning, but terminate the process when it hits some limit? In fork processes it could be great but when dealing with threads it won't work Adding this to FPM won't help anyway - FPM doesn't use threads. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 15.04.2010 12:54, Ferenc Kovacs wrote: Adding this to FPM won't help anyway - FPM doesn't use threads. You meant won't hurt? No, I mean implementing it in PECL/memtrack would be better since this way you add it to all non-threaded SAPIs. While adding it to FPM means that other non-threaded SAPIs will have to do it in an other way. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 15.04.2010 15:03, Ferenc Kovacs wrote: Yeah, this could be implemented there, but it seems that its not actively developed, last release 0.1 beta more than a year ago. In this case 'not actively developed' means 'it works and no bugs were found/reported', so I don't see it as a disadvantage. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
On 15.04.2010 15:17, Ferenc Kovacs wrote: If this is the case, then it should be stable for now, isn't it? I guess you can call it that, yes. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: looyao
On 14.04.2010 06:53, looyao teng wrote: hi, I'm a php programmer, our site use PHP's Imagemagick extension to process images, and this would consume a lot of memory under some circumstances. However, the mainstream PHP's memory management is really weak, so a huge amount of memory would be consumed under high server load. What's worse, this even cause our server to crash frequently. So I rewrote the PHP-FPM , when the memory beyond the limit,child process will exit. You don't need an SVN account to propose a patch. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: looyao
On 14.04.2010 11:20, Ferenc Kovacs wrote: agree, but he did proposed the patch. and it seems that nobody bothered to answer/review: http://www.mail-archive.com/internals@lists.php.net/msg45918.html Which definitely doesn't mean he can go ahead and commit it himself. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php and multithreading (additional arguments)
On 01.04.2010 22:38, Stanislav Malyshev wrote: If you do, how you control access to them? Hello locks and the whole can of worms! Most people that think they can program in threads actually are just pushing their luck until some complex interaction leaves their app malfunctioning in a bizarre way and them without any means to debug it. Well, I don't agree with the statement above, but I do believe that if you're competent enough to use threads, then you're competent enough to write in C/C++. Not to mention that a high-performance multi-threaded daemon written in PHP is a total nonsense - that's exactly the task C/C++ do much better/faster. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php and multithreading (additional arguments)
On 01.04.2010 22:54, Pierre Joye wrote: are we talking about having a thread safe PHP or parallel-like features available in user land? The sooner needs some love to be actually true, while most of the issues come from external libs. The later makes little or no sense. We're talking about threads in userspace, of course. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 25.03.2010 21:30, Michael Shadle wrote: 2010/3/25 Jérôme Loyet jer...@loyet.net: ** Default Section ** Talking about redundancy. When there is more than one pool, there is several parameters which remain the same. Why should we type them several time ? The idea is to define a special pool, which will not be started but only be used as a template with default values for other pools. Common parameters will be set in the default pool and in each pool only specifics parameters will be set. here some example in the two previous cases Redundancy can be addressed by includes. I was thinking of creating an RFC for php.ini file support of includes, but FPM should support includes either - whether it is it's own INI file, the same XML file it's always been, whatever. It should be added to the FPM RFC. You can as well stop declaring (!?) what FPM should and what it shoud not and start doing something useful instead. Writing some code might be a good start for you. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 09:36, Stanislav Malyshev wrote: fpm.myworker.server.start_servers = 20 fpm.myworker.php_defines.memory_limit = 64M etc. It's not that bad. Not that bad doesn't sound very convincing. I'd personally prefer something better than that. As for spaces in pool names - come on, you're not going to write a novel there. No programming language allows spaces in identifiers and we manage to live with it :) No, I'm not going to write a novel. But I'm sure many users would like to use domain name as a pool name. As you might guess, fpm.www.blah.com.php_defines is not going to work, too. It shouldn't be part of php.ini, but it'd be nice if it was part of php config system. It has nothing to do with PHP config system, it's a different thing and it has it's own configuration. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 01:16, Zeev Suraski wrote: For me it is a requirement before the code makes it into a released version of PHP, and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). I think you're missing something. I don't care if FPM is in or out of the core. The only thing I get in case if it's accepted is more troubles as I'll have to maintain it. Nevertheless, I feel that it's a good thing, therefore I'm pushing it in. But if somebody wants me to rewrite a substantial and well-tested part of the code in order to use another syntax style just because XML is too complex for mere mortals - I won't do it. If there are any volunteers to do this - go ahead, let's see what happens. If there are none - fine, I have enough stuff to maintain already. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 11:29, Zeev Suraski wrote: I think you're missing something. I don't care if FPM is in or out of the core. FWIW, I don't think it's a good start for a component that goes into our distribution. In this case I'm willing to take responsibility for doing the conversion, but for the record, if someone proposes to put a component into the PHP distro and refuses to implement the feedback (not every last piece of anecdotal feedback, but the key points) Key points is exactly what under question here. Taking into account that the maintainer of the branch (along with other people) agrees with me, I tend to think this point is not so major as you think. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FPM RFC
Hello all. Derick (and other people) asked me to create an RFC for FPM describing what it is and why do we need it. Quite.. ahem.. laconic version of such RFC can be found here: http://wiki.php.net/rfc/fpm I'm open for your questions. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 08:15 PM, Jani Taskinen wrote:
23.3.2010 18:42, Antony Dovgal wrote:
Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what
it is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here:
http://wiki.php.net/rfc/fpm
I'm open for your questions.
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)
I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with lots
of
if (fcgi_is_fastcgi()) { as you can now see in cgi_main.c.
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some
stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them
later).
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 10:26 PM, Michael Shadle wrote: - Jerome's put in some statistics functionality, which could be useful in monitoring, etc. - might be nice to mention in the features [I would include only the JSON output though] I mentioned it, albeit briefly: * basic SAPI status info (similar to Apache mod_status) - The config file change, moving from the XML-based php-fpm.conf to using php.ini (I think some work had started on this, but syntax was under debate?) We've discussed this many times and I thought it's pretty clear that php.ini syntax won't fit in this situation - the requirements are completely different. - this will make it easier to adopt I don't see how. If there is any help needed I did get an email from an organization who said they could throw a bit of manpower towards it. They can do it any time - testing and reporting issues is a lot of work. Patches are also appreciated, no need to wait for a 'go ahead' from anyone to do this. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 10:37 PM, Pierre Joye wrote:
hi Tony,
On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal t...@daylessday.org wrote:
Does it really need to be separate SAPI? I mean, just replace the old
sapi/cgi
with it? Keep the name 'cgi' though. :)
I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with
lots of
if (fcgi_is_fastcgi()) { as you can now see in cgi_main.c.
Not sure to follow, are you suggesting to consider FPM as the
sapi/cgi's fastcgi replacement? As Jani is suggesting.
No, I suggest to keep sapi/cgi in place and _add_ sapi/fpm as another sapi
module.
This will also ensure that well-tested and mature sapi/cgi will keep being as
it is.
By the way, how portable is it?
Well, I've already seen a complaint about ARM support missing.
But you're asking about Windows, I guess.
I don't think it has been tested on
windows (some of the key features are not necessary with IIS/FCGI as
they do it already but could be for other web servers).
No, certainly no Windows testing were done that is known to me.
I'm pretty sure it doesn't even compile there.
And to be honest I doubt there is any need to spend time on it.
I would suggest to keep it as a separate sapi for now, or forever if it works.
I'd prefer it to stay separate sapi.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 11:31 PM, Zeev Suraski wrote: It's not clear at all. In fact I think it was very clear that using php.ini syntax (together with sections if necessary) is very much an option, and I think mostly everyone here leaned towards it. Just take a look at it: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM/sapi/fpm/php-fpm.conf.in?revision=292487view=markup How do you propose to describe the same set of options using php.ini syntax? Yes, simple things like value=Yes/No or value=DIR fit just fine into php.ini. But how would decribe a set of pools each with its own set of options? (taking into account that some of these options may override global options) Last time I heard it was proposed to use copy/paste to add 'global' options to each pool =) By using syntax we're using everywhere else for configuration, instead of introducing a brand new one. This is not a php.ini, this is a different config file for a different service. You don't expect Apache to switch to php.ini syntax just because it's nice and familiar, do you? .ini is also easier than XML for mere mortals. Now I was never an XML fan myself, but I think THIS particular XML config file is even easier to read and understand than php.ini. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 11:54 PM, Zeev Suraski wrote: At 22:44 23/03/2010, Jérôme Loyet wrote: In fact with INI syntax, there is a serious missing cause there is no include system shiped with. And with FPM as there is potentialy many vhosts, it's necessary to have an include system to feet all system administrator needs. We were talking about the syntax, not actually using php.ini or PHP's INI subsystem. You can use the ini parser to implement includes without a problem. The point is the XML syntax is already there and it's working fine, thank you. No need to implement something on top of something that wasn't supposed to be used this way. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 00:05, Zeev Suraski wrote: How do you propose to describe the same set of options using php.ini syntax? Yes, simple things like value=Yes/No or value=DIR fit just fine into php.ini. But how would decribe a set of pools each with its own set of options? (taking into account that some of these options may override global options) option... anotheroption... [pool1] option... anotheroption... [pool2] option... anotheroption... Okay, here is XML based config quickly converted to php.ini-style syntax: == [fpm.flobals] pid_file = /usr/local/var/run/php-fpm.pid error_log = /usr/local/var/log/php-fpm.log log_level = notice emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 5s daemonize = yes [fpm.workers] [default] listen_address = 127.0.0.1:9000 listen_options = backlog = -1 owner = nobody group = nobody mode = 0666 [php_defines] sendmail_path = /usr/sbin/sendmail -t -i display_errors = 0 error_log = /var/log/php-error.log log_errors = true [- Uhm, no way to mark the end of the section --] user = nobody group = nobody [pm] style = static max_children = 50 status = /status ping = /ping pong = pong [dynamic] start_servers = 20 min_spare_servers = 5 max_spare_servers = 35 [- Uhm, no way to mark the end of the section --] request_terminate_timeout = 0s request_slowlog_timeout = 0s slowlog = /usr/local/var/log/php-fpm.log.slow rlimit_files = 1024 rlimit_core = 0 chroot = chdir = catch_workers_output = yes max_requests = 500 allowed_clients = 127.0.0.1 [environment] HOSTNAME = $HOSTNAME PATH = /usr/local/bin:/usr/bin:/bin TMP = /tmp TMPDIR = /tmp TEMP = /tmp OSTYPE = $OSTYPE MACHTYPE = $MACHTYPE MALLOC_CHECK_ = 2 [- Uhm, no way to mark the end of the section --] [- Uhm, no way to mark the end of the section --] [- Uhm, no way to mark the end of the section --] [- Uhm, no way to mark the end of the section --] [- Uhm, no way to mark the end of the section --] == I won't discuss how it looks to me, but there is only one problem: it doesn't work. That's because php.ini doesn't support nested sections and without them it turns into a real mess. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 01:08, Zeev Suraski wrote: At 23:58 23/03/2010, Antony Dovgal wrote: Okay, here is XML based config quickly converted to php.ini-style syntax: Here's mine - a bit more representative of how .ini files look instead of trying to convert a nested XML file: I'm sure you understand that nesting makes things much more easier to read. fpm.workers.pool name ASCII only and no spaces.pm.dynamic.start_servers is not my preferred syntax. And yes, this is how it should look like since you're implying that FPM config should be a part of php.ini (otherwise I don't see how these two different files are related at all). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Commits to PHP_5_3
On 03/18/2010 09:44 PM, Raphael Geissert wrote: I would actually be happy if I could build support for dba handlers as separate extensions, but that doesn't seem to be the case. Correct me if I'm wrong. Here I'm talking about adding support for tokyo cabinets as a dba handler, not a complete interface to the multiple tokyo cabinet APIs. Are you sure you want to add it to ext/dba? dba is .. well.. dead, and it sound like a complete waste of time. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 03/16/2010 07:13 PM, Derick Rethans wrote: + merge php-fpm branch? Can't see why not. Is there an RFC for this? No, there are no RFCs on that. Just copy sapi/fpm to 5_4 and you've merged it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 03/16/2010 11:00 PM, Johannes Schlüter wrote: On Tue, 2010-03-16 at 19:11 +0300, Alexey Zakhlestin wrote: + merge php-fpm branch? If we get a trunk which will be released in a foreseeable timeframe we don't need to merge this to 5.3 anymore, which had been an old plan. Tony, do you agree? Makes sense to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scary note for gettype() in docs
On 03/01/2010 11:35 PM, Stan Vassilev wrote: Hi, The gettype() documentation warns people that the returned string is subject to change. Why is there a function that's subject to change in the API? Because life is complicated. Because gettype(test) returns string in 5.x and unicode in 6.0. What exactly are you trying to fix? And what exactly are you proposing? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 01/19/2010 01:30 PM, Jani Taskinen wrote: Funny, I was just thinking the opposite man I wish PHP never allows this :) Can of worms I say, can of worms.. Exactly my thought. Please, let's not open it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache has two versions on my extension loaded!
On 01/15/2010 02:32 AM, Bruce Bailey wrote: Antony Thanks very much for your reply. And yes, you're right, it IS time to upgrade. Unfortunately, ldd only shows shared libraries that are automatically loaded. My php extension is loaded by dlopen, which is not shown by ldd. ldd /path/to/your/extension This is what I meant, of course. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache has two versions on my extension loaded!
On 01/14/2010 02:55 AM, Bruce Bailey wrote: Help! I was patching out a new version of my PHP extension, with a different version as part of the name: libmyext.so.1.0 is now libmyext.so.2.0 I updated php.ini (extension=libmyext.so.2.0) and restarted apache with the graceful option. For some reason, both extensions were loaded simultaneously -- as reported by 'lsof' lsof might be wrong or you need to stopstart your apache. In any case, you should have used ldd instead of lsof. apache version 1.3.37 PHP version 5.2.3 Btw, it's time to upgrade these. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php for android
On 01/10/2010 12:45 AM, Moshe Doron wrote: Quit easy porting, here the instructions: http://www.icomsw.com/~moshe/php-android.php -CC = gcc +CC = /home/git/arm-2009q3/bin/arm-none-linux-gnueabi-gcc -CPP = gcc -E +CPP = /home/git/arm-2009q3/bin/arm-none-linux-gnueabi-gcc -E Such kind of changes is not necessary, you can do it with `CC=path to gcc LD=path to ld ./configure ...` If you remove that, there are only two parts that seem to be really ARM-specific: 1) -export-dynamic - -all-static 2) a patch for zend_float.h Both of them are not clear to me, would you care to explain why are they needed? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] typo: make arguments list clearer
On 16.12.2009 18:20, Jérôme Loyet wrote: Hi tony, here is a patch which makes php-fpm consistent about command line arguments. As php-fpm won't handle file execution from command line, it's not necessary to let extra or wrong arguments to be used. With this patch, it returns usage() if it's not a valid arg. Thanks. I was going to do it myself, but it's nice that you've managed to do it first =) -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] bug: some event from parent might be triggered by children
On 16.12.2009 18:33, Jérôme Loyet wrote: hi tony, this patch correct a behaviour that could happened randomly, depending on the event lib used (epoll, poll, kqueue, ...). There is some case in which an event created by the parent process can be triggered in a child. Some case? Could you elaborate? The patch certainly does no harm, but maybe it's worth investigating why parent events are triggered in child processes? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bug when requesting a non existing file
Committed, thanks. I guess we can also move from the list to private mails and IRC (EFNet, #php.pecl) as I'm sure not many of internals@ subscribers are interested in FPM patches at the moment. On 16.12.2009 20:13, Jérôme Loyet wrote: There is a bug in fpm_main.c. After accepting a request, it's initialized and SG(request_info).path_translated must be set. If it's not set (NULL) nothing is done and the php_execute_script is called without having php_fopen_primary_script() called. It causes segfault: 1- call several time a non existant page (/noexistent.php) 2- call several time an existant page (/test.php) 3- call a non existant page (/noexistent.php) -- the child handling this request segfaults The solution is to return a 404 when SG(request_info).path_translated is NULL. By the way, it corrects a non desired feature (bug ?) as well. When calling a non existent value, it returns a 404 with the following message br / bWarning/b: Unknown: Filename cannot be empty in bUnknown/b on line b0/bbr / br / bFatal error/b: Unknown: Failed opening required '' (include_path='.:/usr/local/lib/php') in bUnknown/b on line b0/bbr / ++ Jerome -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 12:04, Jani Taskinen wrote: 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 12:30, Jani Taskinen wrote: Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) Well, now you've lost me completely. 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users Configurable error messages, huh? 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Configurable error level for certain error messages? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 15.12.2009 15:19, Tjerk Anne Meesters wrote: The only two things that would come up after reading Jani's email is: 1) Make the log string configurable, such as CustomLog in apache CustomLog is needed in Apache because there are so much variables available. Here we have time, pid, function and line. With log_level=debug all of them are printed, in other cases only time gets into the log, which makes perfect sense to me. 2) Configure the log level threshold, though I think that should already be there in the first place. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/feature: apache_like or dynamic spawning (for testing)
On 13.12.2009 22:06, Jérôme Loyet wrote: Hi all, I spent some time working on the missing apache_like feature in FPM. The attached patch is the first version and is for testing. Ok, I'll look at this patch more closely later this day (hopefully). Other patches are already committed, thanks a lot. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/feature: apache_like or dynamic spawning (for testing)
On 13.12.2009 22:06, Jérôme Loyet wrote: Hi all, I spent some time working on the missing apache_like feature in FPM. The attached patch is the first version and is for testing. Committed, thanks! -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-FPM] syntax of configuration file
On 09.12.2009 17:55, Jérôme Loyet wrote: Hi guys, I start a new thread about the syntax that should be used in php-fpm to replace xml. As discussed before, there is different point on view on this subject: - INI to stay in the PHP philosophy / practicals - nginx because it was the will of the original authors We already discussed pros/cons of the two solutions. But why don't we allow several syntaxes ? And let the end user to choose the better one for its need ? No. Thank you. EOD -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 05.12.2009 00:18, Stanislav Malyshev wrote: Hi! You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Just curious - any plans for win32 support? If you want to work on it - sure, no problem. But you know me, I have neither knowledge nor desire to work on it myself. Also a heavy loaded server on Windows is something out of this world to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 05.12.2009 03:25, Michael Shadle wrote: What if it was just a modification to the FCGI SAPI, and the FPM management features, config file parsing, all that were in a standalone daemon. That allows for a lot of changes and such to be done in the daemon portion without having to align it with PHP releases That's the thing I want to avoid, actually. Moving something out of PHP just because you're afraid of its release cycles means you make it harder to maintain, not easier. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 07.12.2009 12:30, Jérôme Loyet wrote: You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Hi tony, I've been working on php-fpm. If I want to submit patches, what is the best way to do it ? Send them to internals@ and CC me, this way they won't be lost for sure. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FPM is available in a separate SVN branch
Hello all. I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch. You can check out its sources using the following command: svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm Building FPM is as easy as `./configure --enable-fpm make install`. After that you need to adjust the default config file (installed into $prefix/etc) and run `php-fpm`. For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for heavy-loaded sites. These features include: - advanced process management with graceful stop/start; - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode); - stdout stderr logging; - emergency restart in case of accidental opcode cache destruction; - accelerated upload support; - slowlog; - fastcgi_finish_request() - special function to finish request flush all data while continuing to do something time-consuming (video converting, stats processing etc.); and some more. You are welcome to test the code and report any issues to me (since it's not fully official, we don't have a category @ bugs.php.net yet). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
On 04.12.2009 16:58, Johannes Schlüter wrote: How big would be the impact in regards to BC and stuff for merging it back in 5_3? If i read the svn log correct it's just a SAPI ... so adding it might be low risk as it only affects people using it. That's right, it's a separate SAPI, it doesn't affect anything beyond sapi/fpm in any way. Is it related to the CGI SAPI codewise? Yes, it uses modified versions of cgi_main.c and fastcgi.c/.h. If yes: would there be plans to merge it in some way or would we have to fix bugs in CGI, FPM and probably CLI which all have the same roots? I'm planning to remove some more unused/unnecessary code from fpm_main.c. I guess this will somewhat reduce the amount of porting between the copy and original file. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] default session serialization
On 26.11.2009 03:43, Stanislav Malyshev wrote: I think it makes sense. One note: your code allows numeric session keys, previously not allowed. Not sure if it's important. This might be important for 32bit-64bit interaction using serialized data. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-s
On 25.11.2009 09:57, Pierre Joye wrote: hi Sebastian, open a bug please :) On Wed, Nov 25, 2009 at 7:54 AM, Sebastian Bergmann s...@sebastian-bergmann.de wrote: Rasmus Lerdorf wrote: rasmus Wed, 25 Nov 2009 01:30:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291283 Log: Someone strap down Jani and give him a sedative please. This makes our toolchain work with the latest versions of autoconf and avoids a lot of end-user grief. Without autoconf2.13 installed, I get the following on my Ubuntu 9.10: I suspect there is no way to fix it. And also no point to fix it, since it still works fine, even with all these warnings. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] No core file being created
On 10.11.2009 16:55, Mark Skilbeck wrote: I'm trying to debug a segfault that's occuring in an extension I'm developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says that if I have PHP configured with --enable-debug (which I do) then whenever PHP crashes a core file should be created in the same directory the file is executing. However, I do not see one. I've even run the command as sudo ($ sudo php /file.php) to make sure PHP has the permissions to write the file. # sudo gdb php gdb r /file.php This way you don't need any core files at all. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug when using foreach with references?
On 22.10.2009 05:37, Richard K Miller wrote: Is this a bug in PHP? Search the bug DB before asking such questions. http://bugs.php.net/bug.php?id=29992 http://bugs.php.net/bug.php?id=39307 http://bugs.php.net/bug.php?id=40065 http://bugs.php.net/bug.php?id=40654 http://bugs.php.net/bug.php?id=41603 http://bugs.php.net/bug.php?id=43501 http://bugs.php.net/bug.php?id=43806 http://bugs.php.net/bug.php?id=43988 http://bugs.php.net/bug.php?id=47388 -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] run-tests now works in HEAD
On 01.08.2009 03:46, Greg Beaver wrote: Hi, Finally found the problem in run-tests crashing, turns out it had nothing to do with the zend engine. Now we can run tests in PHP 6 without random crashes. Thank you! /me goes to enable HEAD tests.. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Official DVCS mirrors, was: Commit freeze (moving to SVN)!
On 07.07.2009 13:55, Thomas Koch wrote: Hi, are there people who're interested to host semi-official GIT-/HG-/BZR-mirrors? Doing an initial GIT-SVN sync causes quite a lot of traffic on the subversion server and if a douzens people set up there mirrors in the next week, this traffic is multiplied. If nobody else will, then I'll surely once setup my own GIT-SVN mirror of PHP. Yes, please do. Where are you going to set it up? Github? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shell_exec, environment, and multithreading servers
On 28.05.2009 17:21, jvlad wrote: Why not to enhance semantic of exec() and backticks functions? Why not to run child process with copy of $_ENV[] instead of current process envrironment? Most likely because nobody uses (and cares of) multithreaded servers. But a patch would be welcome, I guess. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
