php.net |  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
Votes:1
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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
33 - 17 = ?
Subscribe to this entry?

 
 [2011-01-27 17:08 UTC] samfiragabriel at gmail dot com
Description:
------------
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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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

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.

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

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,
Gabriel
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 23:01:28 2024 UTC