Hi!
In the last few days I have been investigating Xdebug bug #2051:
"Segfault on fatal error when setting xdebug.mode via php-fpm pool
config" (https://bugs.xdebug.org/view.php?id=2051).
I have now tracked this down to an unexpectedness in how PHP-FPM handles
extension/module initialisation.
Hello internals,
It would be nice if when using the php-fpm sapi, that phpinfo()
function would report the php-fpm.conf file(s) that it's using to serve
this page. I've moved servers a lot over the last 2 months and each package
maintainer has their own locations for these configuration files.
Hello, internals!
I remember the crazy code for invalidating the opcache/realpath entries
from CLI.
Logic was the following: tool asks for the server name with php-fpm to
connect to via ssh connection, then it prepares a small PHP-file and
uploads it to the temp directory on this server and then
On Mon, Jun 22, 2015 at 9:26 PM, Sebastian Bergmann
wrote:
> On 06/19/2015 05:46 PM, Rasmus Lerdorf wrote:
> > I think this is a symptom of doing deploys incorrectly.
>
> You are right, of course. Thank you for pointing out this layer 8
> problem :-) No clue why I did it different (read: stupid
On 06/19/2015 05:46 PM, Rasmus Lerdorf wrote:
> I think this is a symptom of doing deploys incorrectly.
You are right, of course. Thank you for pointing out this layer 8
problem :-) No clue why I did it different (read: stupid) for a
private project when I know better. Oh, well.
--
PHP Intern
On 06/19/2015 08:43 AM, Sebastian Bergmann wrote:
> Scenario: nginx + PHP-FPM / FastCGI.
>
> The final step of the deployment is updating a symlink to point to the
> new version.
>
> For N <= realpath_cache_ttl seconds after the deployment, some
> filesystem operations fail because of outdat
On 19 June 2015 at 13:43, Sebastian Bergmann wrote:
> Scenario: nginx + PHP-FPM / FastCGI.
>
> The final step of the deployment is updating a symlink to point to the
> new version.
>
> For N <= realpath_cache_ttl seconds after the deployment, some
> filesystem operations fail because of outd
Scenario: nginx + PHP-FPM / FastCGI.
The final step of the deployment is updating a symlink to point to the
new version.
For N <= realpath_cache_ttl seconds after the deployment, some
filesystem operations fail because of outdated realpath cache entries.
Is there a way to signal the PHP-FP
Well, there are two changes there (not sure why "move zlog_set_level() again
shows up twice in the log"?)
One changes the pm.start_servers calculated default message to a notice (makes
total sense IMO).
The other moves zlog_set_level() so it's called earlier, or else the log level
isn't set ye
Le 17/05/2013 18:44, Remi Collet a écrit :
> Any feedback before I process ?
>From proposal from Jérôme, I have add a new "systemd_interval" option to
configure the interval between 2 systemd notification (0 means disabled,
except initial notification which stay mandatory by design)
Note : this
On 17/05/13 18:44, Remi Collet wrote:
Hi,
Hi,
I plan to allow php-fpm to be aware of systemd and so, use the
type=notify mode.
I'd like to apply to attached patch to 5.4 and 5.5, as this change have
no impact on standard build (need new --with-fpm-systemd build option).
Any feedback before
Le 17/05/2013 18:44, Remi Collet a écrit :
> I plan to allow php-fpm to be aware of systemd and so, use the
> type=notify mode.
Just to be clear on the goal, this allow systemd to display some
information about the health of the service (Status line)
# systemctl php-fpm.service status
Loaded: l
Hi,
I plan to allow php-fpm to be aware of systemd and so, use the
type=notify mode.
I'd like to apply to attached patch to 5.4 and 5.5, as this change have
no impact on standard build (need new --with-fpm-systemd build option).
Any feedback before I process ?
Remi.
diff -up ../sapi/fpm/config
Hi,
For now php-fpm provides and init.d sample script.
I propose to also provide an unit sample file.
During updating systemd management in fedora, I notice it is quite ugly
to rely on configuration file for daemonize option, as user can change
this value (testing purpose) and will break the la
Hi,
Am 07.03.2012 13:32, schrieb Antony Dovgal:
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.s
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_f
Hi,
before I submit a Bug report I wanted to validate if it's a bug or not.
I try to increase the max_execution_time for a test script. What I have
done is to set php_admin_value[max_execution_time] = 100 in the config
for my pool. The phpinfo() output shows this value for
max_execution_time.
2009/12/9 Olivier Hill :
> Hello Michael,
>
> Are you talking about this?
>
> --with-config-file-scan-dir=...
>
> http://www.radwin.org/michael/blog/2006/07/phpini_hacks_withconfigfil.html
oh, duh - I guess I am. Except it would be nice to have it inside of
php.ini itself and not defined at compil
Hello Michael,
Are you talking about this?
--with-config-file-scan-dir=...
http://www.radwin.org/michael/blog/2006/07/phpini_hacks_withconfigfil.html
Regards,
Olivier
2009/12/9 Michael Shadle :
> 2009/12/9 Jérôme Loyet :
>
>> is there a way to include files ?
>> include /etc/php-fpm/*.conf ? w
2009/12/9 Jérôme Loyet :
> is there a way to include files ?
> include /etc/php-fpm/*.conf ? with one file per worker for example ?
>
> I think adding include to ini should not be a problem if it's not already
> done.
I would love to see the php ini file support includes like MySQL does.
Probab
Le 9 décembre 2009 23:25, Tjerk Anne Meesters a écrit :
> Hi,
>
> ini files can be split, so it doesn't all have to be inside one
> monolithic php.ini
is there a way to include files ?
include /etc/php-fpm/*.conf ? with one file per worker for example ?
I think adding include to ini should not b
Hi,
ini files can be split, so it doesn't all have to be inside one
monolithic php.ini
I agree that repetition doesn't look nice; it would be nice to have
something like:
[fpm.worker.worker1]
listen = 127.0.0.1:1900
uid = webservice
Etc.
Didn't really pay attention to those pool settings, but
Le 9 décembre 2009 20:56, Michael Shadle a écrit :
> 2009/12/9 Jérôme Loyet :
>
>> do you mean that it would be included in the global php.ini file ? I
>> never imagine that. For me it's an independant conf file
>> (/etc/php-fpm.conf for example).
>
> correct. I don't see any reason for a differen
2009/12/9 Jérôme Loyet :
> do you mean that it would be included in the global php.ini file ? I
> never imagine that. For me it's an independant conf file
> (/etc/php-fpm.conf for example).
correct. I don't see any reason for a different configuration file anymore
--
PHP Internals - PHP Runtime
Le 9 décembre 2009 20:44, Michael Shadle a écrit :
> I see it more like:
>
> fpm.global.daemonize = yes
> fpm.global.error_log = /var/log/php-fpm.log
>
> or skip global:
>
> fpm.daemonize = yes
> fpm.error_log = /var/log/php-fpm.log
>
>
> for each worker pool:
>
> fpm.worker1.name = pool1
> fpm.wo
I see it more like:
fpm.global.daemonize = yes
fpm.global.error_log = /var/log/php-fpm.log
or skip global:
fpm.daemonize = yes
fpm.error_log = /var/log/php-fpm.log
for each worker pool:
fpm.worker1.name = pool1
fpm.worker1.address = 127.0.0.1:9000 ; or socket
fpm.worker1.uid = www-data
fpm.wo
Le 9 décembre 2009 19:17, Michael Shadle a écrit :
> 2009/12/9 Zeev Suraski :
>
>> We should be using INI unless there are compelling reasons against it, now
>> that this project becomes a part of the PHP source tree. As far as I can
>> tell there are no such compelling reasons and it can actuall
2009/12/9 Zeev Suraski :
> We should be using INI unless there are compelling reasons against it, now
> that this project becomes a part of the PHP source tree. As far as I can
> tell there are no such compelling reasons and it can actually map quite
> nicely into INI, hence, that's what we shoul
At 19:44 09/12/2009, Jérôme Loyet wrote:
So let have the question another way:
Do we keep XML or do we switch to something else ? If so, which format ?
I and some others think xml is not appropriate here because of the
complexity. So I do think there is a need to change.
INI or other ?
INI is u
On 09.12.2009, at 20:44, Jérôme Loyet wrote:
> Le 9 décembre 2009 17:16, Pierre Joye a écrit :
>> hi,
>>
>> 2009/12/9 Jérôme Loyet :
>>
> 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
>
Le 9 décembre 2009 17:16, Pierre Joye a écrit :
> hi,
>
> 2009/12/9 Jérôme Loyet :
>
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
>>>
>>
>> a
Hi!
I think multiple syntaxes is an unnecessary complication, and they don't
serve any useful purpose - neither of those syntaxes allow you to do
something important that others don't.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...
hi,
2009/12/9 Jérôme Loyet :
>>> 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
>>
>
> and why of that ? Why is it already EOD wihtout arguing ? php-fpm
Hi,
I know little aobut FPM but:
On Wed, 2009-12-09 at 15:55 +0100, Jérôme Loyet wrote:
> 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. Several syntaxes makes testing harder, is
Le 9 décembre 2009 15:57, Antony Dovgal a écrit :
> 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 th
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
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/
Hi!
I believe that Dmitry was interested in actually *replacing* the FastCGI
SAPI with it (or at least patching it 100%) - the configuration options
and "userland" usage of it is where I am not sure how it would "bundle"
with PHP properly. It uses a different config syntax (not ini compatible)
On Fri, Jun 26, 2009 at 12:14 PM, Stanislav Malyshev wrote:
> Hi!
>
> It would be great if someone would examine the impact of adopting it
>> as the FastCGI SAPI replacement or looking at what hooks are required
>> to get it in and perhaps keep the "userland" stuff in PECL...
>>
>
> Why it needs
Hi!
It would be great if someone would examine the impact of adopting it
as the FastCGI SAPI replacement or looking at what hooks are required
to get it in and perhaps keep the "userland" stuff in PECL...
Why it needs to replace existing fcgi SAPI? I would think it is better
to have it just a
Andrei has turned the project over to me, and I am trying to keep it
going full steam ahead.
Rasmus told me the only thing stopping it from being adopted into PHP
or PECL was the license. That has now changed.
I don't believe it can be done in PECL, as it needs too many changes
in PHP core.
It w
So if I'd like to see this added to the source, I'd have to convince the
author? It's been almost two years since that thread...
On Tue, Jun 2, 2009 at 2:00 PM, Hannes Magnusson wrote:
> On Tue, Jun 2, 2009 at 19:46, Eddie Drapkin wrote:
> > I don't know how popular, or well known, this little
On Tue, Jun 2, 2009 at 19:46, Eddie Drapkin wrote:
> I don't know how popular, or well known, this little tool is, but I was
> wondering if there was ever any consideration for it to be merged into the
> main CVS tree and distributed with part of PHP, instead of a 3rd party
> patch. Link: http://
I don't know how popular, or well known, this little tool is, but I was
wondering if there was ever any consideration for it to be merged into the
main CVS tree and distributed with part of PHP, instead of a 3rd party
patch. Link: http://php-fpm.anight.org/
I'm pretty sure this is the right list,
On 24.10.2007 11:21, Stanislav Malyshev wrote:
>>> Hi, This was posted by the author of nginx (http://nginx.net/) a high
>>> performance web-server/reverse proxy on the nginx mailing list
>>>
>>> http://php-fpm.anight.org/
>>>
>>> Pages are primarily in Russian so if somebody can read/comment/blog
Hi, This was posted by the author of nginx (http://nginx.net/) a high
performance web-server/reverse proxy on the nginx mailing list
http://php-fpm.anight.org/
Pages are primarily in Russian so if somebody can read/comment/blog
about it, would be very much appreciated
From what I understand, t
On 24.10.2007 06:07, Yusuf Goolamabbas wrote:
> Hi, This was posted by the author of nginx (http://nginx.net/) a high
> performance web-server/reverse proxy on the nginx mailing list
>
> http://php-fpm.anight.org/
>
> Pages are primarily in Russian so if somebody can read/comment/blog
> about it,
Hi, This was posted by the author of nginx (http://nginx.net/) a high
performance web-server/reverse proxy on the nginx mailing list
http://php-fpm.anight.org/
Pages are primarily in Russian so if somebody can read/comment/blog
about it, would be very much appreciated
Regards, Yusuf
--
Yusuf Go
48 matches
Mail list logo
