# [PHP-FPM] syntax of configuration file - Thread: https://externals.io/message/46363 - Original archive: https://news-web.php.net/php.internals/46363 - Started by jerome@loyet.net on 2009-12-09T14:55:48+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #46363 — jerome@loyet.net — 2009-12-09T14:55:48+00:00 URL: https://externals.io/message/46363#46363 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 --- ## #46365 — jerome@loyet.net — 2009-12-09T15:11:11+00:00 URL: https://externals.io/message/46363#46365 Le 9 décembre 2009 15:57, Antony Dovgal a écrit : > > > […] > > 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. --- ## #46366 — johannes@php.net — 2009-12-09T16:14:24+00:00 URL: https://externals.io/message/46363#46366 · In reply to: #46363 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 --- ## #46367 — Pierre Joye — 2009-12-09T16:16:36+00:00 URL: https://externals.io/message/46363#46367 · In reply to: #46365 hi, 2009/12/9 Jérôme Loyet : > > […] > > 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 --- ## #46368 — Stanislav Malyshev — 2009-12-09T17:36:42+00:00 URL: https://externals.io/message/46363#46368 · In reply to: #46363 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 --- ## #46369 — jerome@loyet.net — 2009-12-09T17:44:40+00:00 URL: https://externals.io/message/46363#46369 · In reply to: #46367 Le 9 décembre 2009 17:16, Pierre Joye a écrit : > hi, > > 2009/12/9 Jérôme Loyet : > > > […] > > 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 --- ## #46370 — Alexey Zakhlestin — 2009-12-09T17:49:50+00:00 URL: https://externals.io/message/46363#46370 · In reply to: #46369 > Le 9 décembre 2009 17:16, Pierre Joye a écrit : > > […] > > 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. --- ## #46371 — Zeev Suraski — 2009-12-09T18:10:58+00:00 URL: https://externals.io/message/46363#46371 · In reply to: #46369 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 --- ## #46372 — Michael Shadle — 2009-12-09T18:17:09+00:00 URL: https://externals.io/message/46363#46372 · In reply to: #46371 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 should use. +1 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. --- ## #46375 — jerome@loyet.net — 2009-12-09T19:17:56+00:00 URL: https://externals.io/message/46363#46375 · In reply to: #46372 Le 9 décembre 2009 19:17, Michael Shadle a écrit : > 2009/12/9 Zeev Suraski : > > > […] > > +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 ... --- ## #46376 — Michael Shadle — 2009-12-09T19:44:46+00:00 URL: https://externals.io/message/46363#46376 · In reply to: #46375 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. --- ## #46377 — jerome@loyet.net — 2009-12-09T19:52:52+00:00 URL: https://externals.io/message/46363#46377 · In reply to: #46376 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.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). --- ## #46378 — Michael Shadle — 2009-12-09T19:56:38+00:00 URL: https://externals.io/message/46363#46378 · In reply to: #46377 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 --- ## #46380 — jerome@loyet.net — 2009-12-09T20:15:24+00:00 URL: https://externals.io/message/46363#46380 · In reply to: #46378 Le 9 décembre 2009 20:56, Michael Shadle a écrit : > 2009/12/9 Jérôme Loyet : > > > […] > > 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 ? --- ## #46388 — Tjerk Anne Meesters — 2009-12-09T22:25:27+00:00 URL: https://externals.io/message/46363#46388 · In reply to: #46380 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 a écrit : > > […] > > 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 --- ## #46391 — jerome@loyet.net — 2009-12-09T23:12:03+00:00 URL: https://externals.io/message/46363#46391 · In reply to: #46388 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 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 ... > > > > > > […] > > > -- > -- > Tjerk --- ## #46396 — Michael Shadle — 2009-12-10T02:01:56+00:00 URL: https://externals.io/message/46363#46396 · In reply to: #46391 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. 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. --- ## #46397 — Olivier Hill — 2009-12-10T02:12:42+00:00 URL: https://externals.io/message/46363#46397 · In reply to: #46396 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 : > > > […] > > 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/ --- ## #46398 — Michael Shadle — 2009-12-10T02:19:32+00:00 URL: https://externals.io/message/46363#46398 · In reply to: #46397 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 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.