[PHP-FPM] syntax of configuration file

15 years ago by jerome@loyet.net — view source

unread

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 ?

It's possible to imagine a default syntax: INI. and let the user to
choose another one. There is many ways to do so:

Add a prefix to the file choose from command line:
php-fpm -y ngx:/etc/php-fpm.conf
php-fpm -y nginx:/etc/php-fpm.conf
php-fpm -y ini:/etc/php-fpm.conf
php-fpm -y yaml:/etc/php-fpm.conf
...
a Shebang in all configuration file (if none it's considered as ini)
#!ini
#!nginx
#!ngx
#!yaml
autodetection

I think this could be a good idea which will, I hope, satisfy us all.
Moreoever, this could be easly extended from futures end-user needs.

I've already started (and almost finished) to hack php-fpm to move
from xml to nginx. I can and want make this work. But we have to meet
a general approval here.

Hope this help.

++ jerome

15 years ago by johannes@php.net — view source

unread

Hi,

I know little aobut FPM but:

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 more confusing to users
(read two tutorials and they use completely different syntaxes, ...) and
should be avoided. That just sounds like pain.

johannes

15 years ago by Stanislav Malyshev — view source

unread

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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 15:57, Antony Dovgal tony@daylessday.org a écrit :

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

and why of that ? Why is it already EOD wihtout arguing ? php-fpm just
started in PHP core and there is willing from people to help and make
php-fpm better, which I tought was the final goal.

15 years ago by Pierre Joye — view source

unread

hi,

2009/12/9 Jérôme Loyet jerome@loyet.net:

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 just
started in PHP core and there is willing from people to help and make
php-fpm better, which I tought was the final goal.

It is, however I have to agree with Tony here, adding a fpm specific
syntax makes little sense. Or do you have any killing arguments for
this new syntax (like not possible to do it otherwise, stoping point
etc.)?

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 17:16, Pierre Joye pierre.php@gmail.com a écrit :

hi,

2009/12/9 Jérôme Loyet jerome@loyet.net:

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 just
started in PHP core and there is willing from people to help and make
php-fpm better, which I tought was the final goal.

It is, however I have to agree with Tony here, adding a fpm specific
syntax makes little sense. Or do you have any killing arguments for
this new syntax (like not possible to do it otherwise, stoping point
etc.)?

I don't have killing arguments I just came with a discussion which
seems fair here. Now it's xml and before it's been integrated there
were discutions about changing it to nginx. So I bring back the
discution here.

about multiple syntax it was a proposal which was about to make all
users happy but the complexity and the confusion is a good argument, I
heard it.

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 used widely in PHP and users know it. But it's not well adapted
for the actual php-fpm configuration organisation. (properties in
sections or subsections). If choosed how will it be organized ?

If we want something else than XML and INI, we can use ngxin like or
yaml configuration file, or other ...

We have to decide to go forward here.

++ Jerome

15 years ago by Alexey Zakhlestin — view source

unread

Le 9 décembre 2009 17:16, Pierre Joye pierre.php@gmail.com a écrit :

hi,

2009/12/9 Jérôme Loyet jerome@loyet.net:

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 just
started in PHP core and there is willing from people to help and make
php-fpm better, which I tought was the final goal.

It is, however I have to agree with Tony here, adding a fpm specific
syntax makes little sense. Or do you have any killing arguments for
this new syntax (like not possible to do it otherwise, stoping point
etc.)?

I don't have killing arguments I just came with a discussion which
seems fair here. Now it's xml and before it's been integrated there
were discutions about changing it to nginx. So I bring back the
discution here.

about multiple syntax it was a proposal which was about to make all
users happy but the complexity and the confusion is a good argument, I
heard it.

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 used widely in PHP and users know it. But it's not well adapted
for the actual php-fpm configuration organisation. (properties in
sections or subsections). If choosed how will it be organized ?

If we want something else than XML and INI, we can use ngxin like or
yaml configuration file, or other ...

as much as I like yaml, it's not a good choice here (because it would add extra dependency)

what about json?
php has nice json encoder and decoder

still, if ini can be adapted without much struggle we should use it.

15 years ago by Zeev Suraski — view source

unread

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 used widely in PHP and users know it. But it's not well adapted
for the actual php-fpm configuration organisation. (properties in
sections or subsections). If choosed how will it be organized ?

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 should use.

Zeev

15 years ago by Michael Shadle — view source

unread

2009/12/9 Zeev Suraski zeev@zend.com:

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 should use.

multiple syntaxes is not a good idea (sorry Jerome :))

it maps to existing PHP configuration syntax and if this is to be in
core, that makes sense.

I would just like to see how the ini file syntax ideas come out
though. Sounds like there's options.

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 19:17, Michael Shadle mike503@gmail.com a écrit :

2009/12/9 Zeev Suraski zeev@zend.com:

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 should use.

+1

multiple syntaxes is not a good idea (sorry Jerome :))

Don't worry for me it was just a proposal :)

it maps to existing PHP configuration syntax and if this is to be in
core, that makes sense.

I would just like to see how the ini file syntax ideas come out
though. Sounds like there's options.

OK so it seams to become clear. So INI it will be (even if I don't
like it but it's logic so I'm fine with it).

Now let's talk about detail of INI.

The specs are:
1- there is a set of key/value pairs
2- each key/value pair is present in a path of sections (from no
section (global parameters) to N sections (specific parameters like
worker pool)

What do you think of the following implemenation:

sections and subsections are separated with a single character dot or slash.
sections can be start with brackets ([worker] [worker.listen])
section can be ended with a special bracket section : empty one []
(if it's authorized by the php ini parser) or something else like
[end_section]
key/value pair respect the INI syntax of course (key = value)

which will looks like something like:

;global options
daemonize = yes
error_log = /var/log/php-fpm.log

;pool 1
[worker] ; start section
name = pool1
chroot = /var/www/docs/pool1
[worker.listen]
address = 127.0.0.1:9000
owner = www
[end_section] ; end section so move back to [worker]
user = www;
group = www;
[worker.env] ; start subsection
hostname = $hostname
[worker.defines] ; start a subsection at the same level as the
previous one, so it ends the previous one implicitely
error_log = /var/www/logs/pool1/php.log

;pool 2
[worker] ; new section it closed all the previous ones ...
name = pool2
...

15 years ago by Michael Shadle — view source

unread

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.worker1.gid = www-data

OR array style...

fpm.worker('pool1').name = pool1
fpm.worker('pool1').address = 127.0.0.1:9000 ; or socket
fpm.worker('pool1').uid = www-data
fpm.worker('pool1').gid = www-data

for nested options can't it be

fpm.worker1.foo.bar.baz = value

(or the alternative array style for worker1)

These would all need to be PHP_INI_SYSTEM or the max level they can
be. I don't think it makes sense to be able to modify any of them.

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 20:44, Michael Shadle mike503@gmail.com 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.worker1.address = 127.0.0.1:9000 ; or socket
fpm.worker1.uid = www-data
fpm.worker1.gid = www-data

OR array style...

fpm.worker('pool1').name = pool1
fpm.worker('pool1').address = 127.0.0.1:9000 ; or socket
fpm.worker('pool1').uid = www-data
fpm.worker('pool1').gid = www-data

for nested options can't it be

fpm.worker1.foo.bar.baz = value

(or the alternative array style for worker1)

using array like described will made conf file unreadable and very
hard to read and write (repeated words ...)

These would all need to be PHP_INI_SYSTEM or the max level they can
be. I don't think it makes sense to be able to modify any of them.

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).

15 years ago by Michael Shadle — view source

unread

2009/12/9 Jérôme Loyet jerome@loyet.net:

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

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 20:56, Michael Shadle mike503@gmail.com a écrit :

2009/12/9 Jérôme Loyet jerome@loyet.net:

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

In my mind, daemon options (php-fpm) and php conf (extensions and
global php conf) are différent things. Having all in the same file
will be harder to use in a mutualized environment where several
instances php-fpm running. And the goals of the two files or not the
same. Moreover having a complex array syntax is, as I said before,
hard to read and write.

what are thoughts from other on this point ?

15 years ago by Tjerk Anne Meesters — view source

unread

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 I guess those
could be sections as well such as [fpm.pool.pool1]

Le 9 décembre 2009 20:56, Michael Shadle mike503@gmail.com a écrit :

2009/12/9 Jérôme Loyet jerome@loyet.net:

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

In my mind, daemon options (php-fpm) and php conf (extensions and
global php conf) are différent things. Having all in the same file
will be harder to use in a mutualized environment where several
instances php-fpm running. And the goals of the two files or not the
same. Moreover having a complex array syntax is, as I said before,
hard to read and write.

what are thoughts from other on this point ?

--

--

Tjerk

15 years ago by jerome@loyet.net — view source

unread

Le 9 décembre 2009 23:25, Tjerk Anne Meesters datibbaw@php.net 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 be a problem if it's not already done.

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 I guess those
could be sections as well such as [fpm.pool.pool1]

pool and worker are the same ... it's pool of workers in fact :)

The simpliest way is to have only one level of section

[fpm] ; for global conf
pid = /var/run/php-fpm.conf
[fpm.worker.default]
listen_address = 127.0.0.1:9000
listen_ower = www ; in case of using unix socket instead of inet
pm = static ; or dynamic
max_children = 15
start_servers = 1; only for dynamic
chroot = /var/www/pool1
user = www
...
[fpm.worker.admin]
listen_address = 127.0.0.1:9001
user = www_admin
...

Le 9 décembre 2009 20:56, Michael Shadle mike503@gmail.com a écrit :

2009/12/9 Jérôme Loyet jerome@loyet.net:

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

In my mind, daemon options (php-fpm) and php conf (extensions and
global php conf) are différent things. Having all in the same file
will be harder to use in a mutualized environment where several
instances php-fpm running. And the goals of the two files or not the
same. Moreover having a complex array syntax is, as I said before,
hard to read and write.

what are thoughts from other on this point ?

--

--

Tjerk

15 years ago by Michael Shadle — view source

unread

2009/12/9 Jérôme Loyet jerome@loyet.net:

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.

Probably would make distribution packaging a lot easier especially
with PECL extensions.

!includedir /whatever/php.d/*

Something like that is what MySQL uses. Then worker files could be
programmatically generated as well.

15 years ago by Olivier Hill — view source

unread

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 mike503@gmail.com:

2009/12/9 Jérôme Loyet jerome@loyet.net:

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.

Probably would make distribution packaging a lot easier especially
with PECL extensions.

!includedir /whatever/php.d/*

Something like that is what MySQL uses. Then worker files could be
programmatically generated as well.

--
http://www.olivierhill.ca/

15 years ago by Michael Shadle — view source

unread

2009/12/9 Olivier Hill ohill@php.net:

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 compile-time (what if it is
undefined? The user is out of luck unless they compile themselves?)

I guess I spaced out, now that I think about it, I have seen
/etc/php.d I think in some people's phpinfo(), I just have never used
it.

[PHP-FPM] syntax of configuration file

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.

Cheers,

--

--

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.