[Console] #47809 remove exit() call in last SignalHandler #48299
Conversation
|
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
It is possibly a breaking change, as some of the users may or may not introduce own handlers to bypass this. Not sure if chanelog or doc changes needed |
bbf315e to
7f44f7b
Compare
|
That's a behavior change, so it cannot be merged in 5.4. It needs to target 6.3. |
|
@fabpot I've rebased to 6.3 and added changelog entry. Phrasing may be a bit to complex, I've opened to suggestions |
|
Thank you @akuzia. |
This PR was merged into the 6.3 branch. Discussion ---------- [Console] Fix a test when pcntl is not available | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | ~ | License | MIT | Doc PR | ~ Same as #48694, about #48299. Commits ------- 2ad8bb1 [Console] Fix a test when pcntl is not available
With the following code (only): #[AsCommand(
name: 'loop',
)]
class LoopCommand extends Command
{
protected function execute(InputInterface $input, OutputInterface $output): int
{
while (true) {
echo "hello\n";
usleep(100_000);
}
return Command::SUCCESS;
}
}when I hit CTRL+C, it does not stop anymore. this is legit since we remove the I'll work on it ASAP |
…dling signals (lyrixx) This PR was merged into the 6.3 branch. Discussion ---------- [Console] Add support for managing exit code while handling signals | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | yes | New feature? | yes | Deprecations? | yes (new method in interrface) | Tickets | Fix #48340 | License | MIT | Doc PR | Signal handling is hard! This commit fixes an issue introduced in bb7779d, see this [comment](#48299 (comment)) for more information. Symfony registers by default 4 signals, the most common ones: `SIGINT`, `SIGTERM`, `SIGUSR1`, and `SIGUSR2`. When no signal handler are registered, the default behavior is to stop the execution of the current script, to replication PHP default behavior. That's why we had a call to exit(0), before bb7779d and that's why it must be restored. However, the concerns raised in the [issue](#47809) are valid, and we should provided a solution for this. Now we have the following features: * By default, we exit, like PHP does by default on `SIGINT`, `SIGTERM`; * It's possible to tell via the event to not exit, by calling `$event->abortExit()`; * It's possible to tell via the event to exit with a custom code, by calling `$event->setExitCode($code)`; * It's possible, via the `SignalableCommandInterface` to tell via the command to not exit, by returning `int|false` from `handleSigbal()` method * Fixed case when there is not event to dispatch at all, but the command register some I think we have all we need now. I added more tests to ensure we don't break anything in the future. --- Sorry for the massive ping here, but this is bit like an a house of cards to make it work in any case. I hope I didn't miss anything. ping `@akuzia` `@lcobucci` `@GromNaN` `@olegpro` Commits ------- 1650e38 [Console] Add support for managing exit code while handling signals
This PR possibly introduces some breaking changes.
Remove last SignalHandler
exit()call inApplication:doRunCommandintroduced in df57119.For more context see #47809