Duplicate signals when commands called via Artisan::call

[momala454]

Laravel Version

12.20.0

PHP Version

8.4.10

Database Driver & Version

No response

Description

Each time a call to \Illuminate\Support\Facades\Artisan::call() is done, it store the signal handler without clearing the old ones.

Steps To Reproduce

class TestBug2 extends \Illuminate\Console\Command implements \Symfony\Component\Console\Command\SignalableCommandInterface
{
    /**
     * The console command name.
     *
     * @var string
     */
    // phpcs:ignore
    protected $signature = 'TestBug2';

    /**
     * The console command description.
     */
    // phpcs:ignore
    protected $description = 'TestBug2';

    /**
     * Execute the console command.
     */
    public function handle(): void
    {
        echo "hello from TestBug2\n";

        \Illuminate\Support\Facades\Artisan::call(TestBug3::class);
        \Illuminate\Support\Facades\Artisan::call(TestBug3::class);
        \Illuminate\Support\Facades\Artisan::call(TestBug3::class);
        \Illuminate\Support\Facades\Artisan::call(TestBug3::class);
        sleep(20);
    }

    /** @return int[] */
    public function getSubscribedSignals(): array
    {
        return [SIGINT, SIGTERM, SIGQUIT];
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        \Illuminate\Support\Facades\Log::notice("Command " . get_class($this) . " Kill asked via signal " . $signal . " on " . gethostname());

        return false;
    }
}

<?php

declare(strict_types=1);

namespace App\Console\Commands;

use Magileads\Database\DB;
use Magileads\Exceptions\UnexpectedException;
use Magileads\Models\IntegrationsEmail\AccountType;

/**
 * Class TestBug
 *
 * @category Console_Command
 */
class TestBug3 extends \Illuminate\Console\Command implements \Symfony\Component\Console\Command\SignalableCommandInterface
{
    /**
     * The console command name.
     *
     * @var string
     */
    // phpcs:ignore
    protected $signature = 'TestBug3';

    /**
     * The console command description.
     */
    // phpcs:ignore
    protected $description = 'TestBug3';

    /**
     * Execute the console command.
     */
    public function handle(): void
    {
        echo "hello from TestBug3\n";
    }

    /** @return int[] */
    public function getSubscribedSignals(): array
    {
        return [SIGINT, SIGTERM, SIGQUIT];
    }

    public function handleSignal(int $signal, int|false $previousExitCode = 0): int|false
    {
        \Illuminate\Support\Facades\Log::notice("Command " . get_class($this) . " Kill asked via signal " . $signal . " on " . gethostname());

        return false;
    }
}

When doing php artisan testBug2 and doing

kill -3 (pid) during the sleep(20)
it will generate the following output

hello from TestBug2
hello from TestBug3
hello from TestBug3
hello from TestBug3
hello from TestBug3
[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug2 Kill asked via signal 3 on c6168f1b4100  

[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug3 Kill asked via signal 3 on c6168f1b4100  

[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug3 Kill asked via signal 3 on c6168f1b4100  

[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug3 Kill asked via signal 3 on c6168f1b4100  

[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug3 Kill asked via signal 3 on c6168f1b4100  

What I expect :

hello from TestBug2
hello from TestBug3
hello from TestBug3
hello from TestBug3
hello from TestBug3
[2025-07-21 11:16:36] development.NOTICE: Command App\Console\Commands\TestBug2 Kill asked via signal 3 on c6168f1b4100  

Which means the class Symfony\Component\Console\SignalRegistry\SignalRegistry is filling for each call to Artisan::call, the array $this->signalHandlers

I'm scheduling console commands using queues, so the worker is calling a lot of time Artisan::call, so it will use more and more memory to fill the array signalHandlers, and when sending a signal, it will generate X lines of notice "Kill asked", X being the number of time the schedule have been called

[macropay-solutions]

@momala454 interesting how even if the TestBug3 commands are finished and exited during the sleep 20, you still get the log for them.

But Laravel should auto handle the signals in the queuing system and if you run the worker in daemon mode it will exit after the current job is processed. So, the question is: Why do you manually subscribe to signals in your commands?

[momala454]

due to the fact that commands don't output stdout and stderr, I moved my commands to queues. But for "simplicity", I created a "Scheduler" job, which will call "Artisan::call" for my commands, so I don't have to rewrite my commands to be "queuable".

I manually subscribe to signals to be able to stop commands before they finish (because they can last hours).
On my actual command code, i'm setting a variable to "true" once I receive a signal, and I regularily monitor the value of that variable during the execution of the command. If true, I will stop the execution cleanly.

you're right, TestBug3 shouldn't even display the message "kill asked" as it's finished.

[macropay-solutions]

@momala454 to tackle the reason you use queues for this you can solve it by reading this

Now if you still want to use queues and make the commands signal aware, we were under the impression that it is out of the box offered by laravel, how else would a blue green deployment work also for the scheduler.

It appears that your implementation makes them aware.

The conclusion is that in blue green deployments, the long running commands are killed before they finish... and so we have work to do....

[momala454]

I already spent a lot of time reading all solutions offered for the problem of stdout/err, but none of them was working properly.

[macropay-solutions]

For us the linked one works for the past year with no issues.
It basically logs through queue.

[momala454]

actually I discarded the method to create a job for each log because I didn't liked a lot this solution which could even make infinite loop if the job itself generate a log

[macropay-solutions]

The job does not regenerate a new job to log, but logs to stdout directly. Only the BG process/command generates a job/message so, the infinite loop does not happen.

  Process::fromShellCommandline($this->buildCommand(), base_path(), [
                        CustomStreamHandler::LOG_VIA_QUEUE_JOB => CustomStreamHandler::LOG_VIA_QUEUE_JOB,
                    ], null, null)->run();

      protected function write(array $record): void
      {
  
          if (self::LOG_VIA_QUEUE_JOB !== \env(self::LOG_VIA_QUEUE_JOB)) {
              parent::write($record);
  
              return;
          }

[momala454]

Ok thanks, but what about the initial issue, can it be fixed (easily?) or it's an expected side effect ?

[macropay-solutions]

We will leave laravel team deal with that. We thank you for the heads-up. We are implementing SignalableCommands as we speak in our projects to avoid commands being killed unexpectedly on deploys.

UPDATE
for BG scheduled commands the sigterm must be forwarded to those processes

https://stackoverflow.com/a/61745416

for pid in $(ps -eo pid,cmd | grep '[a]rtisan' | awk '{print $1}'); do
    (kill -TERM "${pid}" > /dev/stdout 2>&1 || echo "kill -TERM ${pid} exited with non-zero code") &
done

[macropay-solutions]

Ok thanks, but what about the initial issue, can it be fixed (easily?) or it's an expected side effect

@momala454 we looked into it. At the moment the only workaround would be to use

php artisan queue:work --once

for your queue worker. We use it also like that to avoid the limitations the daemon mode brings to the table (just like octane).

This will still not solve the duplicate signals during the same job but at least you don't persist them between jobs.

Unseting the handlers is not easy as they are a list of callbacks for each type of signal

    public function register(int $signal, callable $signalHandler): void
    {
        if (!isset($this->signalHandlers[$signal])) {
            $previousCallback = pcntl_signal_get_handler($signal);

            if (\is_callable($previousCallback)) {
                $this->signalHandlers[$signal][] = $previousCallback;
            }
        }

        $this->signalHandlers[$signal][] = $signalHandler;

        pcntl_signal($signal, $this->handle(...));
    }

Note

    public function handle(int $signal): void
    {
        $count = \count($this->signalHandlers[$signal]);

        foreach ($this->signalHandlers[$signal] as $i => $signalHandler) {
            $hasNext = $i !== $count - 1;
            $signalHandler($signal, $hasNext); //..................................see here that you have a $hasNext flag
        }
    }

So you could avoid the logging but this will not handle the memory issue.

[macropay-solutions]

Another solution
{--max-jobs=0 : The number of jobs to process before stopping}

php artisan queue:work --max-jobs=10

[momala454]

thanks for the workarounds

[crynobone]

Artisan::call() is a common approach to run commands outside of CLI environment. In the above example, there is only a single PID via the initial command but at the same time multiple command registered signal handlers. You should use Process to initiate child process so that would generate a separate PID and main command can send a signal to clear it. as an example:

framework/src/Illuminate/Foundation/Console/ServeCommand.php

Lines 129 to 153 in c82b43b

	$process = $this->startProcess($hasEnvironment);
	while ($process->isRunning()) {
	if ($hasEnvironment) {
	clearstatcache(false, $environmentFile);
	}
	if (! $this->option('no-reload') &&
	$hasEnvironment &&
	filemtime($environmentFile) > $environmentLastModified) {
	$environmentLastModified = filemtime($environmentFile);
	$this->newLine();
	$this->components->info('Environment modified. Restarting server...');
	$process->stop(5);
	$this->serverRunningHasBeenDisplayed = false;
	$process = $this->startProcess($hasEnvironment);
	}
	usleep(500 * 1000);
	}

[momala454]

thanks but I do not want to run the commands in a separate PID

[momala454]

The documentation does not say anywhere that we are not supposed to call Artisan::call without a separate pid

[macropay-solutions]

@momala454 what did you choose as solution?

[momala454]

hello. I've added a boolean property on my commands which indicate if the signal must be handled.
When the command start, I set it to false. When the command ends, I set it to true.
On the method "handleSignal" I verify if it's true. In this case I do nothing. Else, I process the signal and set the bool to true also to prevent it to be called multiple times.

It does not solve the infinite filling of the signalHandlers array, but I've tested and each time I call Artisan::call, it seems to only add less than 2kb of memory usage. So the memory leak is quite small, and if the total memory usage is above the configured value, it will automatically restart the queue:work anyway

edit: i'm testing it, I don't know yet if it will works properly

[macropay-solutions]

Be aware of the job --memory in laravel/lumen see #56077 (comment)

Your case will work only if the php.ini memory is bigger than the --memory from the work command, if they are the same it will not work as you expect. Also if more processes fill the php ini memory it will not work as you expect.

[momala454]

i'm aware of this, the memory_limit from php is higher than the --memory from work.
The --memory parameter only verify between jobs if the memory is not above the limit, and the php ini memory will be the limit also during the jobs.
I just have to set a php init memory limit high enough compared to the --memory worker limit

[macropay-solutions]

Do you run a dedicated container for the worker to not be affected by the other processes that handle http request, scheduler etc?

[momala454]

sheduler, worker, http handler are each separated