Re: PHP-FPM socket disappearing
Hi Bob!
On 2015-Jun-17 16:19, Bob Proulx wrote:
> Proxy One wrote:
> > I installed Jessie on my new server few days ago and moved website
> > that run previously on Centos 5.
>
> Welcome! :-)
Thanks! I'm actually using Debian few last years. :)
>
> > I'm using Apache and PHP-FPM.
>
> I have become an Nginx + php5-fpm advocate in recent years. If you
> decide you would like to give it a try post something and I will show
> my configurations for it. (Not that I am a master of it by any means.
> Just a daily user of it.)
I'm using Nginx myself for a few other machines, but this one must stay
with Apache. There are lot of rewrite rules, that I couldn't adapt to
Nginx.
> > Currently, there is only one website on that server, but I still
> > configured pool for it. What's happening is that, after some time,
> > at least once a day, socket that should be listening for that user
> > disappears, ...
> >...
> > Looking at /dev/shm/ directory, user-php.sock is really missing, but
> > default php5-fpm.sock is still there.
>
> Odd!
>
> > I have this block in VirtualHost section for that website:
> > <IfModule mod_fastcgi.c>
> > Alias /php5-fcgi /dev/shm/pdfconve-php.fcgi
> > </IfModule>
> >...
> > And there is also
> > FastCGIExternalServer /dev/shm/user-php.fcgi -socket /dev/shm/user-php.sock -pass-header Authorization -flush -appConnTimeout 2 -idle-timeout 60
> > in apache conf.
>
> Hmm... Is that right? It is working for you so it must be. And
> since the disappearing fpm socket shouldn't be related I am going to
> ignore my ignorance of the above here.
I put that line in conf-enabled/php5-fpm.conf. Otherwise, Apache
wouldn't know it should go to /dev/shm/user-php.sock for fcgi requests.
> > Pool configured:
> >
> > [user]
> > listen = /dev/shm/user-php.sock
> > listen.owner = user
> > listen.group = www-data
> > listen.mode = 0660
> > user = user
> > group = user
> > pm = dynamic
> > pm.max_children = 40
> > pm.max_requests = 2048
> > pm.start_servers = 30
> > pm.min_spare_servers = 10
> > pm.max_spare_servers = 35
> > request_terminate_timeout = 305
>
> Why use /dev/shm/user-php.sock as the socket path? The Jessie-style
> location would be in /var/run/user-php.sock AFAICS. (I don't see how
> that would be related to your socket dissappearing.)
I used that path on Centos machines and it worked. I saw that Debian
uses different default path, but figured it should work either way. I
also used /dev/shm so it's created in RAM (tmpfs). I figured it would be
quicker this way.
> > There is nothing interesting in php-fpm error log. There are some errors like this:
> > NOTICE: [pool user] child 32719 exited with code 0 after 76324.921427 seconds from start
> >
> > followed by this line:
> > NOTICE: [pool user] child 29909 started
> >
> > but I don't think that's relevant.
>
> Is that just hitting your max_requests limit and exiting? In which
> case that would be normal operation.
>
> > Any idea why this is happening and how to prevent it?
>
> I am running php5-fpm on several servers. I as a matter of course set
> up my own custom pool configurations with a different socket name.
> But always in /var/run. I have not had any problems with with the
> socket disappearing. One is on Jessie 8, one on Sid, the rest on
> Wheezy 7. I haven't seen any endemic problem assocatied with php5-fpm.
>
> The first thing I would try is to move the socket location out of
> /dev/shm (which is symlinked to /run/shm in Jessie 8) and see if the
> behavior stops. If so then it must be related to that location. If
> not then it rules that out as a suspect.
I changed path, so all socket are in /var/run now. Will see if that
solves the problem.
> I would tend to also set up a monitor that would run very often, once
> every minute wouldn't be too often, to check for the presence of the
> socket file. If it dissappears then have it notify me immediately so
> I could look to see what else happened around that same time period.
> Because if it is getting removed I would think that something must be
> removing it and that something will hopefully leave an audit trail.
>
> Bob
Good idea. I usually use Zabbix to monitor websites uptime, but PCU on
that server just died.
Thanks for your help, Bob! Much appreciated.
Reply to: