[5.5] Allow graceful handling of SIGTERM in queue workers

[elliotfehr]

I would like to be able to gracefully shutdown my application when sending a SIGTERM to a running queue daemon.

The current behavior traps SIGTERM signals and waits for the queue worker to process the current message, however it then treats the signal as a SIGKILL and does not gracefully shutdown.

[taylorotwell]

What else would you be doing when catching this event?

[elliotfehr]

Closing connections to my queueing server.

[taylorotwell]

Can you show an example of that though?

[sisve]

I've got some jobs that override the pcntl_signal stuff to add custom timeout handling. (I kill off external processes that my job started which I presume has hung when the timeout occurs.)

It's reasonable that we get a WorkerStopping event when the worker stops, but is it possible to also add a JobTimedOut event with a reference to the job, just as the JobProcessing/JobProcessed/JobFailed events?

On the other hand, that posix_kill(getmypid(), SIGKILL); is meant to really really hard kill our process without executing any registered shutdown handlers... yet we're now talking about adding functionality to run things on timeouts and the following shutdown...

[elliotfehr]

@taylorotwell thanks for merging! Here is an example use case (pseudo code):

Queue::stopping(function () {
        Queue::connection('queue-connection')->close();
});

@sisve I agree that we shouldn't be adding logic to a method intended to SIGKILL, however the current behavior traps SIGTERM and runs posix_kill(getmypid(), SIGKILL);, which is improper handling of SIGTERM. It would be ideal if sending a SIGTERM resulted in a call to $this->stop() as opposed to $this->kill(), but this would require a small refactor of this class.

[GrahamCampbell]

Might be an idea to wait a bit, then send a kill if not terminated?