Symfony version(s) affected

6.4.8 (and probably 7.x, 6.x and before?)

Description

the documentation for signals in console claims:

Symfony doesn't handle any signal received by the command (not even SIGKILL,
SIGTERM, etc). This behavior is intended, as it gives you the flexibility to
handle all signals e.g. to do some tasks before terminating the command.
https://github.com/symfony/symfony-docs/blob/f3056736e5d9a4a8d551467a4d3e8272787c1425/components/console/events.rst?plain=1#L245-L247

However, this is not true for (at least) the standalone usage, for SIGINT and SIGTERM, when no event dispatcher is set. In these cases a signal handler is installed that does apparently prevent the default behaviour.

As is, unless also subscribing to SIGINT/SIGTERM with SignableCommandInterface and exiting in those cases, the process will keep running, since the default behaviour is prevented due to some registered handlers that don't provide the default behaviour.

Since the code hasn't changed much, I suppose this weird behaviour still exists for symfony 7+

How to reproduce

standalone usage of symfony/console with a command implementing the SignalableCommandInterface and subscribing for example to just SIGTERM. handleSignal can do whatever.

	public function getSubscribedSignals(): array
	{
		return [\SIGTERM];
	}

SIGINT in a standard shell (Ctrl-c) ceases to work - presuming stty is available (Terminal::hasSttyAvailable() is true), due to a handler being registered:

Possible Solution

Since it's unclear, what those handlers are for, it's unclear how to fix this in code.

The obvious workaround of subscribing to those two signals as well is error-prone (since you have to remember). Adding a warning to the documentation might also help if this (supposed) bug is not going to be fixed.