Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Does the error happened again since (is it reproductible) ? If so, It would be
great to have a stacktrace of the last segfault.
Do you still have the error log? I'd like to see what was just before and after
the "Bad file descriptor" lines.
Do you have, by any chances, reached any ulimit limitations (like number of open
files) ? This could maybe explain the "Bad file descriptor" error (but not the
others errors)
If you have any clue on how to reproduce the problem, it would be very useful to
fix what seems to be an important bug to me.
thx a lot

[2012-05-23 22:34 UTC] phpbug2012 at tgabber dot mine dot nu

-Status: Feedback+Status: Assigned

[2012-05-23 22:34 UTC] phpbug2012 at tgabber dot mine dot nu

Hi,
The bug is not reproducible as such, however it has happened 3 more times with exactly the same symptoms, with uptimes for fpm varying from 2 days to 5 days. After this I changed the fpm pool configuration files to have catch_workers_output = no (I'd mistakenly thought that this had to be yes to have php errors logged to syslog) and the bug has not resurfaced so far (maximum uptime reached with this config 16 days).
I'm afraid I don't have anything else from the log files now other than what I included in the initial bug report. However I did thoroughly check the logs at the time and there were no other errors either from php or any other service.
There are no ulimits in force on the server and I doubt I ran out of file descriptors as checking /proc/sys/fs/file-nr just now shows only 2528 out of 392117 used.
I'm reluctant to change the config back to gather more information on the bug as this is a production server and the bug if it hits has a severe impact. I do have a backup machine (with the same config) that I could experiment on, but without knowing exactly how to trigger the bug and no real-world load I don't know how useful that would be.

I think there is an easier way to trigger this (and probably something that I'll open as a separate bug):
i) Include a library function in an extension.
ii) Don't include the library in the linking step for php-fpm.
iii) Watch the error log fill up with:
[24-Jul-2014 18:58:27] NOTICE: [pool www] child 22710 started
[24-Jul-2014 18:58:27] WARNING: [pool www] child 22710 exited with code 127 after 0.044963 seconds from start
[24-Jul-2014 18:58:27] WARNING: [pool www] child 22710 said into stderr: "php-fpm: pool www: symbol lookup error: /usr/local/lib/php/extensions/no-debug-zts-20131226/imagick.so: undefined symbol: GetMagickVersion"
Once this happens you need to kill -9 the php-fpm master process to stop it spawning pool workers.
Obviously there shouldn't be errors like this in an extension, but also PHP-FPM shouldn't become unresponsive and start spawning workers like crazy.

Ok, so FPM basically starts the children, but they die immediately (for a reason) and FPM master process starts the new ones.
I can think of adding some option that would limit the number of children spawned per second, or probably abort the whole process if N children were created in the last N seconds, but that kind of solution looks quite hacky to me.

[2014-07-25 13:07 UTC] Danack at basereality dot com

I'd recommend being inspired by aka copying the behaviour of Supervisord.
http://supervisord.org/subprocess.html
Basically it does what it probably the best behaviour of:
i) If child processes exist too quickly, put them in a 'back off' state, to rate limit the number of processes attempting to be started.
ii) If they still fail to start after a reasonable number of retries stop trying to start it for now.
Admittedly, sounds like a big task for something that should be a rare event.

[2015-08-03 03:25 UTC] kobenews at cox dot net

I think this issue is related to a bug I just posted. Same behavior where php-fpm restarts the process over and over again, causing php-fpm master to use 100% cpu. The test script is a little bit simpler, though requires exec() and running a SSH command using multiplexing.
https://bugs.php.net/bug.php?id=70185&edit=2