Similar questions have been asked about this but none have seemed to shed any light on this issue.

I am using PHP 5.6.18 on Ubuntu 14.04. The server its on is an in-office server with an 8 core CPU (not sure exact model) and 8 gb of RAM. This server has run without so much as a peep for about 2.5 years, I have done maintenance on it and it was originally on Ubuntu 12.04 with an older version of php, but upgraded it as time went on. The last time I did any updating was around 6 months ago and no issues.

The general setup is nginx passing requests to apache for cms development, and we have various work applications running directly off of nginx.

However in the last few days, PHP-FPM (CLI/APACHE PHP works fine) seems to crash every 5 or so minutes, sometimes it lasts for longer, even typically fine overnight. There is no load on the server itself, Logs only show that php timed out on the request, and then will not process any further requests until restarted.

The weird thing is nothing has been done to the server recently, this just started up randomly about 3 days ago with no noticeable cause. Every effort (resintalling php/mysql, restarting whole server, ect) has ended in failure.

Here is part of my main nginx config (I have changed these values many times now trying various things, right now most is disabled).

   #client_header_timeout 600;
   #client_body_timeout 600;
   #fastcgi_read_timeout 600;
   client_max_body_size 2048m;
   #fastcgi_buffers 8 4k|8k;
   #fastcgi_buffers 8 128k;
   #fastcgi_buffer_size 128k;
   #client_max_body_size 2048M;
   send_timeout 900;
   #fastcgi_read_timeout 3000;
   sendfile on;
   tcp_nopush on;
   tcp_nodelay on;
   keepalive_timeout 65;
   types_hash_max_size 2048;
   # server_tokens off;

   # server_names_hash_bucket_size 64;
   # server_name_in_redirect off;

Here is an error

upstream timed out (110: Connection timed out) while reading response header from upstream

I used to have the timeout at about 10 mins and that worked well considering it was a dev only server, brought it down to 60 seconds to get the errors to come in quicker now.

Anyone else run into this? or know of something it could be that I am just failing to see?

  • Hard to answer without further information - you may want to elaborate on a few things. What do you need to restart? Nginx, Apache or the FPM deamon? Does nginx still serve static assets in this situation? If it does, I would say the PHP related configs would be far more interesting then the nginx one. Especially the FPM pool config and the Apache vhost config (the FastCgiExternalServer directive normally has a timeout setting, too!) and also the php.ini. Also what is the exact error message in the access.log in both apache and nginx? – s1lv3r Mar 4 '16 at 21:32
  • I have done much in the php-fpm.conf www.conf and php.ini but all the settings would be way to much to include, I have them mostly at default though other then switching from www-data to a specific user. I will add the exact error message to the question though. – Jordan Ramstad Mar 4 '16 at 21:34
  • ... and after this happens your fpm process is locked, so while static assets (e.g. directly acessing a LICENSE.txt or an image) still works anything PHP driven doesn't until you restart the php-fpm deamon? – s1lv3r Mar 4 '16 at 21:43
  • Tested, static assets work fine. – Jordan Ramstad Mar 4 '16 at 21:55
  • Ummm ...that's kind of bad news. Seems like your fpm setup is really broken somehow. I would try catch_workers_output = yes and log_level = debug in your fpm-config. If you haven't changed the error_log the default fpm logfile in Ubuntu is /var/log/php5-fpm.log. Hopefully something comes up. Otherwise it's really a guessing game. – s1lv3r Mar 4 '16 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.