प्रबंधित करने के लिए अपस्टार्ट का उपयोग करना ठीक है, यह मेरे दिमाग को पिघल रहा है। इस तथ्य के साथ ऐसा कुछ हो सकता है कि मुझे अपस्टार्ट को समझ में नहीं आता है और साथ ही मुझे चाहिए। लंबे सवाल के लिए अग्रिम में खेद है।यूनिकॉर्न w/rbenv + bundler binstubs w/ruby-local-exec shebang
मैं रेल ऐप की यूनिकॉर्न मास्टर प्रक्रिया को प्रबंधित करने के लिए अपस्टार्ट का उपयोग करने का प्रयास कर रहा हूं। यूनिकॉर्न्स ऊपर महान शुरू -
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
कि बस ठीक काम करता है: यहाँ मेरे वर्तमान /etc/init/app.conf है। इतना अच्छा नहीं है कि पीआईडी का पता लगाया गया यूनिकॉर्न मास्टर का नहीं है, यह sh प्रक्रिया है। यह स्वयं में और इतना बुरा नहीं है, या तो - अगर मैं ऑटोमैटिकल यूनिकॉर्न शून्य-डाउनटाइम परिनियोजन रणनीति का उपयोग नहीं कर रहा था। क्योंकि मेरे यूनिकॉर्न मास्टर में -USR2 भेजने के कुछ ही समय बाद, एक नया मास्टर उगता है, और बूढ़ा व्यक्ति मर जाता है ... और sh प्रक्रिया भी करता है। तो अपस्टार्ट सोचता है कि मेरी नौकरी की मृत्यु हो गई है, और मैं इसे restart के साथ पुनरारंभ नहीं कर सकता या इसे stop से रोकूं यदि मैं चाहता हूं।
मैंने यूनिकॉर्न लाइन (जैसे: $APP_ROOT/bin/unicorn -c $APP_ROOT/config/unicorn.rb -E production -D) को यूनिकॉर्न को डिमनेनाइज़ करने के लिए -D को जोड़ने की कोशिश कर कॉन्फ़िगरेशन फ़ाइल के साथ खेला है, और मैंने expect daemon लाइन जोड़ा, लेकिन यह भी काम नहीं करता था। मैंने expect fork भी कोशिश की है। उन सभी चीजों के विभिन्न संयोजन start और stop को लटकने का कारण बन सकते हैं, और फिर अपस्टार्ट नौकरी की स्थिति के बारे में वास्तव में भ्रमित हो जाता है। फिर मुझे इसे ठीक करने के लिए मशीन को पुनरारंभ करना होगा।
मुझे लगता है कि कल का नवाब का पता लगाने क्योंकि मैं अपने $APP_ROOT/bin/unicorn लिपि में rbenv + ruby-local-exec कुटिया उपयोग कर रहा हूँ जब/अगर यूनिकॉर्न forking है समस्या हो रही है। संदेश यह है:
#!/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')
साथ ही, ruby-local-exec स्क्रिप्ट इस तरह दिखता है:
#!/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]"
तो वहाँ है कि मैं बारे में चिंतित हूँ वहाँ में एक exec है। यह एक रूबी प्रक्रिया को सक्रिय करता है, जो यूनिकॉर्न को फायर करता है, जो खुद को डिमनीकृत कर सकता है या नहीं, जो सभी पहले sh प्रक्रिया से होता है ... जो मुझे इस बकवास को ट्रैक करने के लिए अपस्टार्ट की क्षमता को गंभीरता से संदेह करता है।
क्या मैं भी ऐसा करने की कोशिश कर रहा हूं? जो मैं समझता हूं, उससे अधिकतम 12 फोर्क की अपेक्षा करने के लिए अपस्टार्ट में expect स्टैन्ज़ा को केवल (daemon या fork के माध्यम से) बताया जा सकता है।
बहुत बढ़िया, इसके लिए धन्यवाद। – codykrieger
एक विस्तृत उत्तर के लिए धन्यवाद! यह सिर्फ मुझे समान स्थिति में भगवान + अपस्टार्ट स्थापित करने में मदद की। – dreikanter