Welcome! Log In Create A New Profile

Advanced

PHP-FPM Signal Handling

Posted by Dai 
Dai
PHP-FPM Signal Handling
June 27, 2009 11:33AM
Hello,

>From the documentation, PHP-FPM handles signals as such:

* SIGINT, SIGTERM: immediate termination
* SIGQUIT: graceful stop
* SIGUSR1: re-open log file
* SIGUSR2: graceful reload of all workers + reload of fpm conf/binary

However, SIGTERM should instead be doing a graceful stop instead of
SIGQUIT, as what SIGQUIT should be doing is a core dump.

Additionally, perhaps SIGHUP should function like SIGUSR2?

Summarised below:

* SIGINT: immediate termination
* SIGTERM: graceful stop
* SIGQUIT: core dump
* SIGUSR1: re-open log file
* SIGHUP, SIGUSR2: graceful reload of all workers + reload of fpm conf/
binary
Re: PHP-FPM Signal Handling
June 27, 2009 02:50PM
Go ahead and add this to the wishlist (http://php-fpm.org/Wishlist)
Does this follow the same pattern that nginx does? I think that was his
original idea when he designed it. Either way if this change is made we'll
need to make sure init scripts are updated too.

On Sat, Jun 27, 2009 at 8:33 AM, Dai wrote:

>
> Hello,
>
> From the documentation, PHP-FPM handles signals as such:
>
> * SIGINT, SIGTERM: immediate termination
> * SIGQUIT: graceful stop
> * SIGUSR1: re-open log file
> * SIGUSR2: graceful reload of all workers + reload of fpm conf/binary
>
> However, SIGTERM should instead be doing a graceful stop instead of
> SIGQUIT, as what SIGQUIT should be doing is a core dump.
>
> Additionally, perhaps SIGHUP should function like SIGUSR2?
>
> Summarised below:
>
> * SIGINT: immediate termination
> * SIGTERM: graceful stop
> * SIGQUIT: core dump
> * SIGUSR1: re-open log file
> * SIGHUP, SIGUSR2: graceful reload of all workers + reload of fpm conf/
> binary
>
>
Dai
Re: PHP-FPM Signal Handling
June 28, 2009 09:19AM
Hello Mike,

I have added it to the list at http://php-fpm.org/Wishlist, and with
detailed information at <http://php-fpm.org/User:Paolo_Rodriguez/
Wishlist:_Proper_Signal_Handling>.

And yes, nginx understands these signals and processes them properly
in the standard way mentioned.

As far as I know the init scripts use SIGQUIT and SIGUSR2.
Implementing a change like this would not make the init script
nonfunctional as SIGQUIT will still exit after creating the core dump
(note though that while the general quitting effect is the same, I
believe for SIGQUIT the action should be force kill after core
dumping, compared to a SIGTERM which can just use the exit call), and
SIGUSR2 will not be removed nor changed.


On Jun 28, 2:50
Re: PHP-FPM Signal Handling
June 28, 2009 01:39PM
My worry isn't that it will become nonfunctional, just not 100% aligned. We
should make sure the init script (well, it's not really an init script but a
symlink to the php-fpm script) handles these signals and labels them
correctly.

On Sun, Jun 28, 2009 at 6:19 AM, Dai wrote:

>
> Hello Mike,
>
> I have added it to the list at , and with
> detailed information at Wishlist:_Proper_Signal_Handling>.
>
> And yes, nginx understands these signals and processes them properly
> in the standard way mentioned.
>
> As far as I know the init scripts use SIGQUIT and SIGUSR2.
> Implementing a change like this would not make the init script
> nonfunctional as SIGQUIT will still exit after creating the core dump
> (note though that while the general quitting effect is the same, I
> believe for SIGQUIT the action should be force kill after core
> dumping, compared to a SIGTERM which can just use the exit call), and
> SIGUSR2 will not be removed nor changed.
>
>
> On Jun 28, 2:50 am, Michael Shadle wrote:
> > Go ahead and add this to the wishlist (http://php-fpm.org/Wishlist)
> > Does this follow the same pattern that nginx does? I think that was his
> > original idea when he designed it. Either way if this change is made
> we'll
> > need to make sure init scripts are updated too.
> >
> >
> >
> > On Sat, Jun 27, 2009 at 8:33 AM, Dai
> wrote:
> >
> > > Hello,
> >
> > > From the documentation, PHP-FPM handles signals as such:
> >
> > > * SIGINT, SIGTERM: immediate termination
> > > * SIGQUIT: graceful stop
> > > * SIGUSR1: re-open log file
> > > * SIGUSR2: graceful reload of all workers + reload of fpm conf/binary
> >
> > > However, SIGTERM should instead be doing a graceful stop instead of
> > > SIGQUIT, as what SIGQUIT should be doing is a core dump.
> >
> > > Additionally, perhaps SIGHUP should function like SIGUSR2?
> >
> > > Summarised below:
> >
> > > * SIGINT: immediate termination
> > > * SIGTERM: graceful stop
> > > * SIGQUIT: core dump
> > > * SIGUSR1: re-open log file
> > > * SIGHUP, SIGUSR2: graceful reload of all workers + reload of fpm conf/
> > > binary
>
Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 161
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready