2011-10-13 25 views
6

Làm cách nào để dừng delay_job nếu tôi đang chạy nó bằng tùy chọn -m "màn hình"? Các quy trình tiếp tục được khởi động lại!Làm cách nào để dừng delay_job nếu tôi đang chạy nó bằng tùy chọn -m "monitor"?

Lệnh tôi bắt đầu delayed_job với là:

script/delayed_job -n 4 -m start 

Các -m chạy một quá trình giám sát chúng sinh sản một quá trình delayed_job mới nếu một người chết.

Lệnh Tôi đang sử dụng để ngăn chặn là:

script/delayed_job stop 

Nhưng điều đó không ngăn cản các quá trình giám sát, mà lần lượt khởi động tất cả các quá trình một lần nữa. Tôi chỉ muốn họ biến mất. Tôi có thể giết họ, tôi có, nhưng tôi đã hy vọng có một số tùy chọn dòng lệnh để đóng toàn bộ điều xuống.

Trả lời

8

Trong capistrano tôi triển khai kịch bản tôi có điều này:

desc "Start workers" 
task :start_workers do 
    run "cd #{release_path} && RAILS_ENV=production script/delayed_job -m -n 2 start" 
end 

desc "Stop workers" 
task :stop_workers do 
    run "ps xu | grep delayed_job | grep monitor | grep -v grep | awk '{print $2}' | xargs -r kill" 
    run "cd #{current_path} && RAILS_ENV=production script/delayed_job stop" 
end 

Để tránh bất kỳ lỗi nào có thể ngừng kịch bản triển khai của bạn:

  • "ps xu" chỉ hiển thị các quá trình thuộc sở hữu của người dùng hiện
  • "xargs -r giết "chỉ gọi lệnh giết khi có điều gì đó để giết

Tôi chỉ giết màn hình delay_job và dừng delay_job deamon theo cách thông thường.

+0

Tôi giết các tiến trình công việc bị trì hoãn theo cách thông thường, sau đó buộc phải tiêu diệt bất kỳ chiến binh nào để đảm bảo. Trong capistrano 3, tôi đang sử dụng 'execute' thay vì' run' – Dex

1

Câu trả lời trực tiếp là bạn phải hủy quá trình giám sát trước. Tuy nhiên AFAIK không phải là một cách dễ dàng để làm điều này, tôi không nghĩ rằng các PID màn hình được lưu trữ bất cứ nơi nào và các DJ bắt đầu và dừng kịch bản chắc chắn không làm bất cứ điều gì thông minh ở đó, như bạn nhận thấy.

Tôi thấy thật kỳ lạ khi tính năng màn hình được đưa vào - tôi đoán Daemons có nó nên bất cứ ai đang viết kịch bản DJ đều cho rằng họ sẽ chuyển tùy chọn đó xuống. Nhưng nó không thực sự có thể sử dụng như nó được.

tôi đã viết một email vào danh sách về vấn đề này một thời gian trở lại, đã không nhận được một câu trả lời: https://groups.google.com/d/msg/delayed_job/HerSuU97BOc/n4Ps430AI1UJ

Bạn có thể xem thêm về giám sát với Daemons ở đây: http://daemons.rubyforge.org/classes/Daemons.html#M000004

Nếu bạn đưa ra một câu trả lời/giải pháp tốt hơn, thêm nó vào wiki tại đây: https://github.com/collectiveidea/delayed_job/wiki/monitor-process

+2

Dường như mọi thứ đã thay đổi trong ba năm kể từ khi câu trả lời này được đưa ra. Sử dụng delay_job 4.0.2, khi -m được chuyển tới 'delay_job -m start', cả hai delay_job.pid và delay_job_monitor.pid được ghi vào tmp/pids và 'delay_job stop' giết chết cả hai quá trình. – KenB

3

Tôi cũng gặp vấn đề tương tự. Đây là cách tôi giải quyết nó:

# ps -ef | grep delay 
root  8605  1 0 Jan03 ?  00:00:00 delayed_job_monitor        
root  15704  1 0 14:29 ?  00:00:00 dashboard/delayed_job        
root  15817 12026 0 14:31 pts/0 00:00:00 grep --color=auto delay 

Ở đây bạn thấy delayed_job quá trình màn hình. Tiếp theo, tôi sẽ tự tay giết các quy trình này và sau đó xóa các PID. Từ thư mục của ứng dụng (/ usr/share/con rối-bảng điều khiển trong trường hợp của tôi):

# ps -ef | grep delay | grep -v grep | awk '{print $2}' | xargs kill && rm tmp/pids/*

Các vấn đề liên quan