Được rồi, điều này đang làm tan chảy bộ não của tôi. Nó có thể có một cái gì đó để làm với thực tế là tôi không hiểu Upstart cũng như tôi nên. Xin lỗi trước cho câu hỏi dài.Sử dụng Upstart để quản lý Unicorn w/rbenv + bundler binstubs w/ruby-local-exec shebang
Tôi đang cố gắng sử dụng Upstart để quản lý quy trình tổng thể Unicorn của ứng dụng Rails. Đây là số /etc/init/app.conf hiện tại của tôi:
description "app"
start on runlevel [2]
stop on runlevel [016]
console owner
# expect daemon
script
APP_ROOT=/home/deploy/app
PATH=/home/deploy/.rbenv/shims:/home/deploy/.rbenv/bin:$PATH
$APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production # >> /tmp/upstart.log 2>&1
end script
# respawn
Điều đó chỉ hoạt động tốt - Unicorn khởi động tuyệt vời. Điều không tuyệt vời là PID được phát hiện không phải là chủ nhân Unicorn, nó thuộc về quá trình sh. Điều đó trong và của chính nó không phải là xấu như vậy, hoặc - nếu tôi đã không sử dụng chiến lược triển khai tự động Unicorn zero-downtime. Bởi vì ngay sau khi tôi gửi -USR2 cho tổng thể Unicorn của tôi, một tổng thể mới sinh ra và cái cũ chết ... và quá trình sh cũng vậy. Vì vậy, Upstart nghĩ rằng công việc của tôi đã chết, và tôi không còn có thể khởi động lại nó với restart hoặc dừng nó với stop nếu tôi muốn.
Tôi đã chơi xung quanh với các tập tin cấu hình, cố gắng để thêm -D vào dòng Unicorn (như thế này: $APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production -D) daemonize Unicorn, và tôi đã thêm dòng expect daemon, nhưng điều đó không làm việc, hoặc. Tôi cũng đã thử số expect fork. Các kết hợp khác nhau của tất cả những thứ đó có thể gây ra start và stop để treo, sau đó Upstart thực sự nhầm lẫn về trạng thái của công việc. Sau đó, tôi phải khởi động lại máy để sửa chữa nó.
Tôi nghĩ Upstart đang gặp sự cố khi phát hiện khi/nếu Unicorn đang tắt vì tôi đang sử dụng rbenv + ruby-local-exec shebang trong tập lệnh $APP_ROOT/bin/unicorn của tôi. Ở đây là:
#!/usr/bin/env ruby-local-exec
#
# This file was generated by Bundler.
#
# The application 'unicorn' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'pathname'
ENV['BUNDLE_GEMFILE'] ||= File.expand_path("../../Gemfile",
Pathname.new(__FILE__).realpath)
require 'rubygems'
require 'bundler/setup'
load Gem.bin_path('unicorn', 'unicorn')
Thêm vào đó, kịch bản ruby-local-exec trông như thế này:
#!/usr/bin/env bash
#
# `ruby-local-exec` is a drop-in replacement for the standard Ruby
# shebang line:
#
# #!/usr/bin/env ruby-local-exec
#
# Use it for scripts inside a project with an `.rbenv-version`
# file. When you run the scripts, they'll use the project-specified
# Ruby version, regardless of what directory they're run from. Useful
# for e.g. running project tasks in cron scripts without needing to
# `cd` into the project first.
set -e
export RBENV_DIR="${1%/*}"
exec ruby "[email protected]"
Vì vậy, có một exec trong đó mà tôi đang lo lắng về. Nó khởi động một quá trình Ruby, nó sẽ làm cho Unicorn, có thể hoặc không thể tự daemon, mà tất cả xảy ra từ một quy trình sh ngay từ đầu ... điều này khiến tôi nghi ngờ khả năng Upstart theo dõi tất cả những điều vô nghĩa này.
Là những gì tôi đang cố gắng làm thậm chí có thể? Từ những gì tôi hiểu, đoạn quảng cáo expect trong Upstart chỉ có thể được thông báo (qua daemon hoặc fork) để mong đợi tối đa là hai nhánh.
Tuyệt vời, cảm ơn vì điều đó. – codykrieger
Cảm ơn bạn đã trả lời chi tiết! Nó chỉ giúp tôi thiết lập Thiên Chúa + Upstart trong tình huống giống hệt nhau. – dreikanter