win32-servicegemを使用してサービスとして実行するように設定された sinatra アプリがあります。アプリは正常に起動しますが、しばらくすると壊れます。ただし、サービスのステータスによると、サービスはまだ実行されていますが、外部またはコンピューター自体からアクセスできないようです。修正する唯一の方法は、サービスを停止して削除し、サービスを再インストールして起動することです.
アプリは通常、自己展開 (ビルド パイプラインのためですが、更新をプッシュした場合のみ) であり、chef によりインストールおよび実行されます。そのセットアップ方法は、chef サーバーがすべてのクックブックを 5 分ごとに実行することであり、それが壊れると思います何とか私のアプリですが、方法がわかりません。
どんな洞察も大歓迎です。
psコードを投稿していないことに気づきましたが、それは何が役立つかわからないためです。何を見る必要があるか教えてください。投稿します。
編集:シェフとは何の関係もないことがわかりました:
いくつかのロギングのおかげで、アプリが 5 秒間のヘルス ping (ワニスによって行われる) への応答を停止する前に約 57 分間実行されていたことがわかり、シェフの実行は 30 分ごとに発生します。 -無関係。
ただし、ステータスはまだ「実行中」であるため、停止しておらず、ログにはデーモンの実行を停止させるエラーが報告されていません。
編集：
ここに私のデーモンコードがあります:
class DemoDaemon < Daemon
def service_main
Object.const_get("GG_Web_#{C_NAME}").run! port: PORT, server: 'thin'
while running?
sleep 100
File.open(Logfile, "a"){ |f| f.puts "#{Time.now} - Service is running" }
end
end
def service_stop
File.open(Logfile, "a"){ |f| f.puts "#{Time.now} - Service stopped" }
exit!
end
end
DemoDaemon.mainloop
編集：
アプリが 50 分前後で応答を停止し、ログ出力なし (例: 例外、サービスの停止など) をギブまたはテイクし、アプリのステータスが として応答することに気付きましたrunning。念のため、ボックスでシェフクライアントを無効にしましたが、アプリはまだ応答を停止しているため、100％シェフではありません.
編集：
また、実際にはログファイルに出力さService is runningれません。Service stopped
編集:私はそれをかなり絞り込みましたが、そうではないことを知っています:
- シェフ
- ソースコードの読み込みメカニズム
- 主な処理、つまりリクエストの処理、データベースからのデータのロードなどを行うアプリの部分 (同じ問題を抱えた 2 つのアプリがあり、原因は両方で同じものと関係があります)
この問題が発生せずに動作していた以前のバージョンの gem にロールバックしましたが、まだ動作しています。
アプリケーションのメインループを作成するために使用しているwin32-systemgemと、sinatraとの相互作用です。
アプリを登録するために使用しているコードは次のとおりです。
binary_path = "#{self.rubypath} #{ROOT.gsub('/','\\')}boot_as_service.rb"
Service.create({
service_name: NAME,
service_type: Service::WIN32_OWN_PROCESS,
description: "#{DESCRIPTION}, running on: #{HOST}:#{PORT}",
start_type: Service::AUTO_START,
error_control: Service::ERROR_NORMAL,
binary_path_name: binary_path,
load_order_group: 'Network',
dependencies: ['W32Time', 'Schedule'],
display_name: NAME
})
主なアプリケーション クラス:
class GG_Web_My_APP < Sinatra::Base
set :show_exceptions, true
set :root, ROOT + NAME
set :server, 'thin'
set :scss, {:style => :compact, :debug_info => false}
Compass.add_project_configuration(File.join(settings.root, 'config', 'compass.rb'))
Tilt.register Tilt::ERBTemplate, 'html.erb'
enable :logging
logging_file = File.open((Object.const_defined?('Logfile') ? Logfile : 'C:\\app.log'), "a")
logging_file.sync = true
use Rack::CommonLogger, logging_file
if ENV['APPLICATION_NAME']
set :environment, :production
set :bind, '0.0.0.0'
end
get '/css/:name.css' do
content_type 'text/css', :charset => 'utf-8'
scss :"/assets/css/#{params[:name]}", Compass.sass_engine_options
end
helpers Sinatra::FormHelpers
helpers Sinatra.const_get("GG_Web_#{C_NAME}")::Helpers
register Sinatra.const_get("GG_Web_#{C_NAME}")::Api
register Sinatra.const_get("GG_Web_#{C_NAME}")::Actions
end
アプリをデーモンとして実行するために使用しているコードを見てきました。
これを修正するには本当に助けが必要です。これを引き起こしている可能性のあるものと修正方法を確認するためのアイデアがまったくありません。
編集：まあ、もう1つ確認できました。それは私のコードでそれを引き起こしているものではありません。それでも停止しましたが、ローカル マシンで実行したままにしていたバージョンは停止しませんでした。サーバーが応答しなくなる原因は、サーバー上で実行されている何かです。
さらに編集：
それはまったく問題ではないことが判明しました、私はまだ何も得ていません
編集：
わかりました、嘘をつくことはできませんでしたので、戻って、system32デーモンクラスを使用せずにアプリをデーモンとして実行することができました. time) 、まあ、サービス gem なしで開始したので、まだハングしているので、他に何ができるのだろうかと思っています。シナトラがハングアップする原因は何ですか?
また、ping localhost返信があれば(0%ロス)でもcurlだと繋がらない。
編集：
Hello World アプリケーションになるまで体系的にすべてを取り除いた後、私の ruby コードとはまったく関係がないと言っても過言ではありません。この時点で、私は:
- デーモンでコードをラップして実行するのではなく、ラックアップを使用してアプリをプロセスとして開始します (ただし、メイン スレッドを手動で強制終了する必要がありますが、アプリは引き続き実行されます)。
- ロギングをオフにしました
- コンパス/サスを取り除きました（他の誰かに明らかにそうしていたので、ぶら下がっているかもしれないと思っていました。それに、付属の機能を使用していないことに気付いたので、それを維持しても意味がありません）
- すべてのモジュールをコメントアウトし、次のようにしました。
get '/' do 'Hello World' end
結局、それはまだ死んでいて、この時点では純粋なシナトラの「ハローワールド」アプリでした。したがって、sinatraに何か問題があるか（他の人がこの問題を抱えていたのではないかと思います）、おそらくサーバーに何かが原因である可能性があります。
それを引き起こしている可能性のあるサーバー上のものはわかりません。しかし、少なくとも私はその解決に一歩近づきました。