Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Messenger] Gracefull stop messenger when ran in Docker FPM Image #43866

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Warxcell opened this issue Nov 1, 2021 · 10 comments
Closed

[Messenger] Gracefull stop messenger when ran in Docker FPM Image #43866

Warxcell opened this issue Nov 1, 2021 · 10 comments

Comments

@Warxcell
Copy link
Contributor

Warxcell commented Nov 1, 2021

Symfony version(s) affected

ALL

Description

Hello, we have web app which uses messenger.
We are using single image for web part and messenger, cronjobs.
The problem is that PHP-FPM doesn't quite follow the standard POSIX signals, so as work-around Docker image for PHP-FPM overrides STOP SIGNAL, which results in non-gracefull killing of containers with messenger, since Messenger only listens for SIGTERM.

My proposal is to make this configurable, and allow every person to choose on which signals to stop the worker.

How to reproduce

Build image which inherits php:${PHP_VERSION}-fpm-alpine, run it with entrypoint/cmd messenger, and run docker stop on that container.

Possible Solution

Make SIGNALS in StopWorkerOnSigtermSignalListener configurable. (SIGTERM by default)

Additional Context

Just give me a green light and I can start working on it.

@Warxcell Warxcell added the Bug label Nov 1, 2021
@Warxcell Warxcell changed the title Gracefull stop messenger when ran in Docekr FPM Image [Messenger] Gracefull stop messenger when ran in Docker FPM Image Nov 1, 2021
@jderusse
Copy link
Member

I'm 👍 for make signal configurable

@Warxcell
Copy link
Contributor Author

Where from should I start ? 5.4 ? Not really sure if this is classificed as bug or feature.

@jderusse
Copy link
Member

That's a new parameter, and so, a new feature for 6.1 (the branch does not yet exist, you need to target 6.0 for the moment)

@wucdbm

This comment has been minimized.

Warxcell added a commit to Warxcell/symfony that referenced this issue Mar 15, 2022
Warxcell added a commit to Warxcell/symfony that referenced this issue Mar 15, 2022
Warxcell added a commit to Warxcell/symfony that referenced this issue Mar 15, 2022
Warxcell added a commit to Warxcell/symfony that referenced this issue Mar 15, 2022
Warxcell added a commit to Warxcell/symfony that referenced this issue Mar 15, 2022
@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@magnetik
Copy link
Contributor

Still relevant to me.

@carsonbot carsonbot removed the Stalled label Jun 16, 2022
@jzecca
Copy link

jzecca commented Jun 16, 2022

Still relevant indeed.

If it can be of any help, here's what we're using as a workaround in the meantime:

# config/services.yaml

services:
    messenger.listener.stop_worker_on_sigterm_signal_listener:
        class: App\EventSubscriber\StopWorkerOnSigquitSignalSubscriber
<?php
# src/EventSubscriber/StopWorkerOnSigquitSignalSubscriber.php

namespace App\EventSubscriber;

use Psr\Log\LoggerInterface;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Messenger\Event\WorkerStartedEvent;

/**
 * Listens to SIGQUIT signal in order to shut down the Messenger worker gracefully,
 * since the PHP-FPM Docker images use SIGQUIT instead of SIGTERM to signal process termination.
 *
 * @see https://github.com/symfony/symfony/issues/43866
 * @see https://github.com/docker-library/php/blob/8007237246d31766d78fb25a4590d289cac545ca/8.1/alpine3.16/fpm/Dockerfile#L251-L253
 */
class StopWorkerOnSigquitSignalSubscriber implements EventSubscriberInterface
{
    public function __construct(
        private readonly LoggerInterface $logger,
    ) {
    }

    public function onWorkerStarted(WorkerStartedEvent $event): void
    {
        pcntl_signal(\SIGQUIT, function () use ($event) {
            $this->logger?->info('Received SIGQUIT signal.', [
                'transport_names' => $event->getWorker()->getMetadata()->getTransportNames(),
            ]);

            $event->getWorker()->stop();
        });
    }

    public static function getSubscribedEvents(): array
    {
        if (!\function_exists('pcntl_signal')) {
            return [];
        }

        return [
            WorkerStartedEvent::class => ['onWorkerStarted', 100],
        ];
    }
}

@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@carsonbot
Copy link

Hello? This issue is about to be closed if nobody replies.

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

fabpot added a commit that referenced this issue Apr 8, 2024
This PR was merged into the 7.1 branch.

Discussion
----------

[Console] Handle SIGQUIT signal

| Q             | A
| ------------- | ---
| Branch?       | 7.1
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Issues        | #43866
| License       | MIT

As both PHP-FPM and NGINX use SIGQUIT for graceful shutdown, I believe it's necessary PHP applications should also support it. It's especially important in cases where you run PHP application in container running php/nginx image, since they override shutdown signal that docker uses to SIGQUIT, see eg. nginx/docker-nginx@3fb70dd

Commits
-------

43016f9 [Console] Handle SIGQUIT signal
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants