2012-03-07 16 views
9

Có lẽ bạn đã nhìn thấy này ...Làm thế nào tôi có thể nói với kỳ lân để hiểu tín hiệu của Heroku?

 
2012-03-07T15:36:25+00:00 heroku[web.1]: Stopping process with SIGTERM 
2012-03-07T15:36:36+00:00 heroku[web.1]: Stopping process with SIGKILL 
2012-03-07T15:36:36+00:00 heroku[web.1]: Error R12 (Exit timeout) -> Process failed to exit within 10 seconds of SIGTERM 
2012-03-07T15:36:38+00:00 heroku[web.1]: Process exited with status 137 

Đây là vấn đề nổi tiếng khi chạy unicorn trên heroku ...

Can Tôi nói với heroku để gửi SIGQUIT? Hay tôi có thể nói với kỳ lân để xử lý SIGTERM là tắt máy duyên dáng?

+0

tôi didin't biết rằng tôi đang cân nhắc lân cho một dự án nhưng điều này làm cho tôi. xem xét lại. Dưới đây là các tín hiệu sử dụng mỏng: https://github.com/macournoyer/thin/blob/master/lib/thin/server.rb#L211 Trong cả hai trường hợp, QUIT báo hiệu tắt máy duyên dáng, nhưng INT và TERM được đổi chỗ. –

+1

BTW, có một yếu tố khác ở đây - heroku sẽ gửi TERM cho quá trình được xác định trong Procfile, nhưng sau đó quá trình đó có trách nhiệm bàn giao tín hiệu xuống khi nó thấy phù hợp. Vì vậy, nếu bạn đang chạy máy chủ của bạn đằng sau bó exec, ngay cả khi heroku đã gửi tín hiệu chính xác bạn sẽ thấy hành vi ở trên vì máy chủ web không nhận được tín hiệu nào cả. Tôi đã nói chuyện để hỗ trợ về điều này và họ đang đưa ra một giải pháp. –

+2

Tôi tìm thấy điều này ngày hôm nay, tôi chưa khám phá nó: https://github.com/ddollar/foreman/wiki/Custom-Signals –

Trả lời

6

Đây là một hack, nhưng tôi đã tạo thành công tệp cấu hình lân để bẫy tín hiệu TERM, ngăn không cho người lân nhận nó và thực hiện tắt máy nhanh chóng. Trình xử lý tín hiệu của tôi sau đó gửi QUIT tín hiệu trở lại chính nó để kích hoạt tắt máy duyên dáng kỳ lân.

Tested với Ruby 1.9.2, Unicorn 4.0.1 và 4.2.1, Mac OS X.

listen 9292 
worker_processes 1 

# This is a hack. The code is run with 'before_fork' so it runs 
# *after* Unicorn installs its own TERM signal handler (which makes 
# this highly dependent on the Unicorn implementation details). 
# 
# We install our own signal handler for TERM and simply re-send a QUIT 
# signal to our self. 
before_fork do |_server, _worker| 
    Signal.trap 'TERM' do 
    puts 'intercepting TERM and sending myself QUIT instead' 
    Process.kill 'QUIT', Process.pid 
    end 
end 

Người ta lo ngại rằng (Tôi tin) xử lý tín hiệu này được kế thừa bởi các quá trình lao động. Tuy nhiên, quy trình công nhân cài đặt trình xử lý TERM của riêng nó, quá trình này sẽ ghi đè lên trình xử lý này, vì vậy tôi không mong đợi bất kỳ vấn đề nào. (Xem Unicorn::HttpServer#init_worker_process @ lib/unicorn/http_server.rb:551

Edit:.. Thêm một chi tiết, khối này mà cài đặt các xử lý tín hiệu sẽ chạy một lần cho mỗi quá trình lao động (vì before_fork), nhưng bất cứ điều gì chỉ đơn thuần là không cần thiết và sẽ không ảnh hưởng này

+2

đây là câu trả lời được chấp nhận bởi vì Patrick đã đưa ra nó năm b4 heroku đã làm ... nhưng xem câu trả lời của Clay cho câu trả lời có thẩm quyền mới nhất –

9

Heroku hiện nay cung cấp hướng dẫn cho đây này: https://blog.heroku.com/archives/2013/2/27/unicorn_rails

tập tin unicorn.rb đề nghị của họ là:

# config/unicorn.rb 
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' 
    Process.kill 'QUIT', Process.pid 
    end 

    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.connection.disconnect! 
end 

after_fork do |server, worker| 

    Signal.trap 'TERM' do 
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT' 
    end 

    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.establish_connection 
end 
Các vấn đề liên quan