|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #53857 Pool definition errors
Submitted: 2011-01-27 17:08 UTC Modified: 2011-02-10 09:06 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: samfiragabriel at gmail dot com Assigned:
Status: Not a bug Package: FPM related
PHP Version: 5.3.5 OS: GNU/Linux
Private report: No CVE-ID: None
 [2011-01-27 17:08 UTC] samfiragabriel at gmail dot com
It seams that if there is an error in the php-fpm config file, lets say in one of the pools, then fpm just dies with an error.

For example, if you define a chroot value in one of the pools, and the directory does not exist, the master process and all the other pools just die upon SIGUSR2.

In a shared hosting environment much of the configuring is done via scripts, and rarely by hand. If one value is erroneous, it would be better if that particular pool is skipped instead of just dying all together.

That way at least only one site will go down instead of all of them.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-28 21:56 UTC]
-Summary: Pool deffinition errors +Summary: Pool definition errors
 [2011-01-29 11:22 UTC]
-Status: Open +Status: Bogus
 [2011-01-29 11:22 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

If one of your configuration line is wrong, it's detected and FPM won't start. 
Here is the example you mentioned (non existant chroot dir) (in this example 
/nowhere does not exist)

# grep ^chroot /path/to/php-fpm.conf
chroot = /nowhere

# ./sapi/fpm/php-fpm
[29-Jan-2011 11:16:34] ERROR: [pool www_chroot] the chroot path '/nowhere' does 
not exist or is not a directory
[29-Jan-2011 11:16:34] ERROR: failed to post process the configuration

If you run php-fpm with --test, you can anticipate an configuration error and 
you won't restart FPM.

If you have a practical case which is not detected by the --test, please open a 
bug report and it'll be corrected.

 [2011-02-10 09:06 UTC] samfiragabriel at gmail dot com

I apologise for the late response, i was on vacation for the past week. Also, sorry if this was not the right way to go about it. I know it is not really a bug, that's why I selected "Feature/Change Request".

I was taking a look at fpm_conf_process_all_pools() and it just seamed like a good place to remove a pool from fpm_worker_all_pools if there is a configuration error for that pool.

But if its a design decision that cannot be changed, then the --test flag is ok. It just seamed like it could be useful to log a configuration error, skip the pool, and continue without starting only that pool.

Thank you for your time and for answering to my post!

Best regards,
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Oct 20 13:03:32 2021 UTC