mirror of
https://github.com/discourse/discourse.git
synced 2026-08-12 05:37:26 +08:00
When pressing Ctrl+C with `bin/ember-cli -u`, the server could appear stuck for up to 60 seconds and stop responding to further Ctrl+C attempts, requiring `kill -9` to terminate. This was most commonly triggered after switching git branches, which could leave workers stuck in native code (autoloading, V8 compilation, etc.), making the slow shutdown path much more noticeable. The root cause was a signal race: when Ctrl+C sends SIGINT to the process group, ember-cli's monitoring thread would also send SIGTERM to the pitchfork supervisor after detecting ember died. This TERM arrived at the pitchfork monitor while it was already performing a hard shutdown (from INT), causing it to abort the hard shutdown and fall back to a slow graceful shutdown with a 60-second timeout. Combined with both bin/ember-cli and bin/pitchfork unconditionally swallowing all subsequent SIGINTs, the user had no way to interrupt. Fixes: - bin/ember-cli: track whether SIGINT was received and skip sending TERM to the server in that case (it already got INT from the terminal) - bin/ember-cli, bin/pitchfork, bin/unicorn: add signal escalation so repeated Ctrl+C can force-kill children as a last resort |
||
|---|---|---|
| .. | ||
| docker | ||
| annotaterb | ||
| bundle | ||
| dev | ||
| ember-cli | ||
| lint | ||
| notify_file_change | ||
| pitchfork | ||
| qunit | ||
| rails | ||
| rake | ||
| rspec | ||
| rubocop | ||
| system_rspec | ||
| turbo_rspec | ||
| unicorn | ||