Limit czasu wyjścia jednorożca na Heroku po przechwyceniu TERM i wysłaniu QUIT

90

Otrzymuję błędy przekroczenia limitu czasu wyjścia R12 dla aplikacji Heroku z systemem jednorożca i sidekiq. Te błędy występują 1-2 razy dziennie i przy każdym wdrożeniu. Rozumiem, że muszę przekonwertować sygnały zamknięcia z Heroku, aby jednorożec zareagował poprawnie, ale pomyślałem, że zrobiłem to w poniższej konfiguracji jednorożca:

worker_processes 3
timeout 30
preload_app true

before_fork do |server, worker|
  Signal.trap 'TERM' do
    puts "Unicorn master intercepting TERM and sending myself QUIT instead. My PID is #{Process.pid}"
    Process.kill 'QUIT', Process.pid
  end

  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.connection.disconnect!
    Rails.logger.info('Disconnected from ActiveRecord')
  end
end

after_fork do |server, worker|
  Signal.trap 'TERM' do
    puts "Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is #{Process.pid}"
  end

  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.establish_connection
    Rails.logger.info('Connected to ActiveRecord')
  end

  Sidekiq.configure_client do |config|
    config.redis = { :size => 1 }
  end
end

Moje dzienniki otaczające błąd wyglądają następująco:

Stopping all processes with SIGTERM
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 7
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 11
Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT. My PID is 15
Unicorn master intercepting TERM and sending myself QUIT instead. My PID is 2
Started GET "/manage"
reaped #<Process::Status: pid 11 exit 0> worker=1
reaped #<Process::Status: pid 7 exit 0> worker=0
reaped #<Process::Status: pid 15 exit 0> worker=2
master complete
Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of SIGTERM
Stopping remaining processes with SIGKILL
Process exited with status 137

Wygląda na to, że wszystkie procesy potomne zostały pomyślnie zebrane przed upływem limitu czasu. Czy to możliwe, że pan wciąż żyje? Czy router powinien nadal wysyłać żądania internetowe do hamowni podczas wyłączania, jak pokazano w dziennikach?

FWIW, używam wtyczki Heroku do wdrażania zero przestojów ( https://devcenter.heroku.com/articles/labs-preboot/ ).

middkidd
źródło
6
Jeśli to pomoże, również mam ten problem bez wtyczki do wdrażania bez przestojów. Mam nadzieję, że ktoś może pomóc lub możesz opublikować odpowiedź, jeśli się zorientujesz. Może skontaktuj się z pomocą techniczną Heroku?
Chris Peters,
Podobnie jak Chris, nie używam zerowych przestojów i mam ten problem. Dzieje się tak pomimo używania zalecanej przez Heroku konfiguracji jednorożca.
imderek
Mam ten sam problem, pomimo używania zalecanej konfiguracji Heroku. Nie ma też żadnego wdrożenia bez przestojów.
elsurudo
Ten sam problem i brak korzystania z wtyczki preboot.
Adrian Macneil
Zauważyłem, że ZWYKLE dzieje się to na hamowniach roboczych. Nie zawsze, ale zwykle.
Chris Peters

Odpowiedzi:

4

Myślę, że twoja niestandardowa obsługa sygnału powoduje tutaj przekroczenia czasu.

EDYCJA: Jestem źle oceniany za niezgodę z dokumentacją Heroku i chciałbym się tym zająć.

Skonfigurowanie aplikacji Unicorn do przechwytywania i połykania sygnału TERM jest najbardziej prawdopodobną przyczyną zawieszenia się aplikacji i nieprawidłowego jej zamknięcia.

Heroku wydaje się argumentować, że przechwycenie i przekształcenie sygnału TERM w sygnał QUIT jest właściwym zachowaniem, aby zmienić twarde zamknięcie w bezpieczne zamknięcie.

Jednak wydaje się, że w niektórych przypadkach powoduje to ryzyko całkowitego braku wyłączenia - jest to przyczyna tego błędu. Użytkownicy doświadczający wiszących hamowni z Unicornem powinni rozważyć dowody i samodzielnie podjąć decyzję w oparciu o podstawowe zasady, a nie tylko dokumentację.

Winfield
źródło
2
Dokumentacja Heroku nadal obejmuje „ Wdzięczne zamknięcie z SIGTERM ” i nie widzę wzmianki o tym, że nie muszę już tego robić na stosie Cedar. Czy masz odniesienie do tego, gdzie można to znaleźć?
Dennis
Nie mogę znaleźć żadnej dokumentacji obsługującej tę odpowiedź. Zgodnie z dokumentacją Unicorn i Heroku, Unicorn nadal używa odwrotnej interpretacji sygnału POSIX.
Josh Kovach
To nie jest prawda. Unicorn nadal nie wyłącza się z wdziękiem bez wyraźnej obsługi sygnału TERM. W artykule Dev Center wspiera ten temat można znaleźć tutaj: devcenter.heroku.com/articles/rails-unicorn#config
skos
Rozumiem, że dokumentacja Heroku mówi, że powinieneś spróbować złapać / przekształcić te sygnały. Próby prawidłowego zamknięcia systemu są najbardziej prawdopodobną przyczyną przekroczenia limitów czasu.
Winfield,