Question

我们正在使用基于官方ruby:2.4.2图片的泊坞窗图片在ECS上运行Rails 5.1应用。

在许多部署中，我们从旧流程中了解到这个例外：

SignalException: SIGTERM - SignalException in at_exit

Backtrace:

[GEM_ROOT]/gems/puma-3.11.0/lib/puma/launcher.rb:397 :in `block in setup_signals`
[GEM_ROOT]/gems/puma-3.11.0/lib/puma/single.rb:106 :in `join`
[GEM_ROOT]/gems/puma-3.11.0/lib/puma/single.rb:106 :in `run`
[GEM_ROOT]/gems/puma-3.11.0/lib/puma/launcher.rb:183 :in `run`
[GEM_ROOT]/gems/puma-3.11.0/lib/puma/cli.rb:77 :in `run`
[GEM_ROOT]/gems/puma-3.11.0/bin/puma:10 :in `<top (required)>`

/usr/local[GEM_ROOT]/bin/puma:21 :in `load`

19 require "bundler/setup"
20 
21 load Gem.bin_path("puma", "puma")

/usr/local[GEM_ROOT]/bin/puma:21 :in `<main>`

我发现this建议将BUNDLE_DISABLE_EXEC_LOAD设置为true可以解决问题，但事实并非如此。

另请注意in at_exit部分。我们的关机是否可能需要太长时间，以便ECS在流程正确终止之前发送另一个SIGTERM？

命令是

"command": [
    "bin/ecs",
    "webserver"
  ]

和bin/ecs是

#!/usr/bin/env ruby

COMMANDS = {
  "webserver" => "puma -C config/puma.rb",
  "sidekiq" => "sidekiq -C config/sidekiq.yml"
}

system("bundle", "exec", "rake", "db:abort_if_pending_migrations")

exit $?.exitstatus unless $?.success?

command = COMMANDS[ARGV.first].split(" ")
exec(*command)

我们这样做是为了避免在某处运行shell，因为它会吞下信号。我们还设置了一个高停止超时，以确保长期运行的sidekiq任务不被杀死：

ECS_CONTAINER_STOP_TIMEOUT=1h

容器退出速度非常快，因此超时不是问题。如果它会被杀死，它也无法报告它，不是吗？

Answer 1

似乎Honeybadger正在报告信号异常，但应该忽略它。它将在3.3.0之后的下一个版本（尚未发布）https://github.com/honeybadger-io/honeybadger-ruby/pull/269

AWS ECS上at_exit中的SignalException

1 个答案: