解决办法是：request_terminate_timeout设置为10s或者一个合理的值，
或者给file_get_contents加一个超时参数。
$ctx = stream_context_create(array(
'http' => array(
'timeout' => 10 //设置一个超时时间，单位为秒
)
));
file_get_contents($str, 0, $ctx);
php-fpm中的request_terminate_timeout最好不要设置
刚转到php-fpm没几天就发现，进入我的joomla后台，firefox偶尔会给我白屏的那种http 503，这种情况仅出现在天翼云的服务器上，而我在国外的同样配置的服务器一点问题都没有，后来发现是request_terminate_timeout的问题。
每次登陆joomla后台，joomla都会去检查是否有更新（检查成功后cache，默认保存该cache 6小时），而且分为joomla主程序和joomla扩展两个部分，如下图：
不出意外的话，服务器会发起两个php进程，分别分配给两个php-fpm children，去连接joomla的官方update服务器。好，问题就来了，我的request_terminate_timeout = 30s，30秒不完成则超时，参见天翼云主机的国际出口相当蛋疼！没错，30秒内，天翼云主机根本无法完成连接joomla更新服务器并检查是否有更新这整个过程。这也很好解释了为什么同样配置的国外服务器就没有问题，因为它们完成上述更细过程仅需要在2~5秒左右。
我的apache超时设置是30秒，php.ini中最长执行时间野是30秒，多年来都没有任何问题，没有30秒还打不开的网页，所以我就没多想给php-fpm的request_terminate_timeout = 30s。经过这次的事情发现此30秒非鄙30秒啊……
php-fpm设置request_terminate_timeout后，php.ini中的max_execution_time和max_input_time都会失效，以php-fpm中的设置为准；
apache+mod_php在timeout后，只会在日志中记录一下，仅此而已。php-fpm中的request_terminate_timeout超时之后，日志中记录http 503的同时，最要命的，它还会直接杀死造成这个http 503的php-fpm child，并生成新的child。
在我的joomla更新这个实例中，就会有两个php-fpm children同时被杀死。而我的天翼云主机是低配，只有一个cpu核心，我也只启动了两个php-fpm children，两个同时死了，我的firefox这边也就http 503 Service Unavailable的白屏了。php-fpm的error_log如下:
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1882, script '/home/onepx/public_html/administrator/index.php' (request: "POST /administrator/index.php") execution timed out (30.004534 sec), terminating
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1882 exited on signal 15 (SIGTERM) after 164.717323 seconds from start
[27-Sep-2014 10:41:06] NOTICE: [pool www] child 1886 started
[27-Sep-2014 10:41:06] WARNING: [pool www] child 1883, script '/home/onepx/public_html/administrator/index.php' (request: "POST /administrator/index.php") execution timed out (30.005201 sec), terminating