問題タブ [upstart]

upstart を使用してデーモンを起動し、node.js (express と connect-redis を使用) http および https サーバー (同じ node .js ファイル内) を実行しています。

http://kevin.vanzonneveld.net/techblog/article/run_nodejs_as_a_service_on_ubuntu_karmic/

起動時はすべて問題なく、すべてのアプリ機能が期待どおりに動作しているように見えますが、一貫して、さまざまな期間 (数時間後、場合によっては 1 日後) の後、デーモン プロセスが強制終了され、私が持っている唯一のログが

デーモン.ログ:

myserver init: myupstartscript メイン プロセス (3410) が ABRT シグナルによって強制終了されました

ノードjsファイルに、次を配置しました：

どれもイベントをキャッチしません。

イベントをシミュレートする方法がわかりません。使ってみたところ

my process.on('SIGABRT',..) はそれらをキャッチします。

私が気づいた他のこと：

• https サーバーなしでサービスを実行すると、クラッシュは発生しません。
• 私の他のログに基づくと、クラッシュはユーザーがトリガーしたイベントによるものではありません
• 私が依存している他のアプリ固有のサービス (redis-server、mongod) は、イベントに関連しているようには見えず、通常どおりサービスを提供し続けます。
• クラッシュ時に再生成するように upstart スクリプトを設定しました。

それを追跡する方法について何か助けはありますか？

私のセットアップ: Linux iLV1 2.6.35.4-rscloud #8 SMP Mon Sep 20 15:54:33 UTC 2010 x86_64 GNU/Linux node v0.5.11-pre

ありがとう。

node.js アプリケーションがあります。

次の内容の Procfile を作成しました。

正しいかどうかはわかりませんが、ルビー宝石の職長で実行してみました。

何も起こりません。プロセスは実行されません。

これを実行する他の方法がある場合は、私がそれを正しく行っているかどうかについてコメントしてください。これは私のローカルです。私が最終的にやりたいことは、最終的に本番環境にデプロイされたときに、upstart を使用してこれをエクスポートすることです。

Foreman (バージョン 0.31.0) を使用してアプリケーションのプロセスを管理しようとしていますが、nginx (nginx/1.0.10 + Phusion Passenger 3.0.11) ではうまくいきません。

私のProcfileからの関連行は次のとおりです。

アプリを起動すると、Foreman は nginx が起動し、すぐに終了したことを報告します。

ただし、フォアマンが別の方法で報告しているにもかかわらず、 nginx は実際には実行されています。

同様に、Upstart にエクスポートする場合:

そして実行するsudo start my_appと、nginxが正常に起動します。ただし、sudo stop my_app nginx は停止しません。走り続けています。

nginx を Foreman と連携させるコツはありますか?

注: Foremanでこの問題を見つけましたが、関連しているのかどうか疑問に思っています。

最近、いくつかのディレクトリをファイルシステム ツリーの別の場所に再バインドできるように、いくつかのエントリを fstab に追加しました。

ただし、/mnt/smb/foo は (Samba サーバー上の) SMB ファイルシステムであり、fstab の前に次のような行があります。

(明らかに、これらの行は匿名化されています)

問題は、起動時に「The disc drive for /home/mishagale/sourcecode/bar is not ready yet or not present.」というエラーが発生することです。を押してマウントをスキップするSと、システムは正常に起動しますが、問題のあるマウントポイントを手動でマウントする必要があります。

Ubuntuが正常にマウントさbarれるまでマウントを試行しないように指示する方法はありますか? fooこれはupstartで可能になるはずですが、どうすればよいかわかりません。

noautoオプションをオンにして、後で実行するようにマウントするスクリプトを設定することもできますが（今のところ）bar、これは私にとっては面倒なことのように思えます.Upstartでそれを行う「適切な」方法を学ぶことに興味があります. .

daemon() 呼び出しを使用する C で書かれたデーモンがあります。

予期せず失敗した場合に、これを復活させたいと思います。

Ubuntu 8.04でかなり古いバージョンのupstart 0.3.9を使用しています。

次のファイル (/etc/event.d/my-daemon) を作成しました。

状態：

始める：

期待どおりに実行すると表示ps aux | grep my-daemonされます。kill -9次に、リスポーンすることを期待して殺しますが、再発行ps auxしてもその後は何も表示されません。私status my-daemonが得ること：

何か案は？

upstart v1.4アプリケーションサーバーを起動するために使用していますunicorn.

構成ファイルは次のupstartようになります。

少なくともディレクトリに対して0774は、プロセスが で実行されることが不可欠です。ug+rwxo+rユーザーとグループは、nginx サーバー、アップロード、スタッフのログインなどで共有されます。

ディレクトリが間違った権限で作成されていることがわかりました。

私の知る限り、私のアプリケーションではこれを引き起こしているものは何もありません。

プロセスにアタッチgdbして を呼び出すcall umask(0)と、有効な umask は75、または になり0o113ます。

gdbセッションは次のとおりです。

の umask は、113に対して作成されたアクセス許可を説明します664。これは、私が見ているように見えます。

ここで私は何を間違っていますか? 新興企業は私のスタンザを無視していますか? スタンザを003ではなくとして定義する必要があり0003ますか? 私のgdbセッションは機能しており、%o printf()構文は正しいですか?

UbuntuボックスでユニコーンWebサーバーを起動（および維持）するためのupstart構成ファイルを作成するのに苦労しています。

respawnとexpectパラメータをどのように設定すればよいですか? respawn有効にすると、プロセスは継続的に再起動されます (その上で、PID が継続的に変化し、古いものがゾンビになっていることがわかります) 。ディレクティブを削除すると、プロセスが終了してもプロセスは再起動されません。

成り上がりのドキュメンテーションによると、expect パラメータが重要である可能性があります。ユニコーンのフォークに関する動作は何ですか? どんな手掛かり？

次のようなサーバー用のUpstartスクリプトがあります。

ただし、アプリはNODE_ENVが本番環境に設定されていることを認識しません。実際、アプリ内でconsole.log（process.env）を実行すると、NODE_ENVまたはCUSTOMが表示されません。何が起こっているのかアイデアはありますか？

ちなみに、NODE_ENV=本番ノードapp.jsは問題なく動作します。

RubygemにUpstart設定ファイルを入れたいです。これが私の現在の最良の推測です

一般に、構成ファイルやその他の種類のスクリプトはgemのどこに配置されますか？

更新：例のパスをからに変更しUpstart/rt_watchdog.confましlib/upstart/rt_watchdog.confた。これは、今のところ使用することにしたものですが、それでも気分が良くありません。

概要

Monit で複数のチェックを組み合わせるにはどうすればよいですか? プロセス アクティビティとファイル コンテンツ/タイムスタンプを確認したい。

長くて退屈な説明

Bukkit Minecraft サーバーを維持するための Monit デーモンに取り組んでいます。いくつかのチェックを行います。現時点では、次のコードがあります。

動作します...しかし遅いです。何か問題が発生した場合、サーバーが終了するまで 20 秒待たなければなりません。しかし、サーバーは時々リロード (構成の更新、メモリのクリーンアップなど) を行い、ほとんど遅延が発生しないため、そのタイムアウトが必要です。サーバーがないtimeout 20 seconds for 2 cyclesと、リロードするとすぐに終了します。

わかりました。実際に問題が発生した場合、サーバーが再起動するまで 20 秒待つのは問題ありません。しかし、ほとんどの場合 (何か問題が発生すると)、サーバー上のすべてのセキュリティ メカニズムが機能しなくなります。

そのため、サーバーが応答しない場合はすぐに再起動する方法を見つける必要がありますが、リロードするときに少し時間がかかります。

私はこのアプローチを取っています: サーバーは、コマンド (サーバーのステータスを確認するために使用するリロードや API 呼び出しを含む) が発行されると、ログファイルに何かを書き込みます。したがって、ログファイルのタイムスタンプは最後のコマンドのタイムスタンプです。リロード中、ファイルには何も書き込まれません。そのため、単純なタイムスタンプ チェックでリロードを検出でき、サーバーが現在リロードしている場合にのみ 20 秒を与えます。