Fabric: Initスクリプトは、デーモンの起動に失敗することがよくあります

Jeff Forcier （ bitprophet ）が投稿しました：

私がテストしているinitスクリプトをインストルメント化しましたが、すべてが同じように実行されているようです（つまり、実際の成功または偽の成功シナリオ）。これは、スクリプト自体が行うapachectl呼び出しの範囲内に問題があることを意味します。

原因が私たちの側にある可能性があることについて考え始めます：

• セミランダムなので、競合状態に悩まされているIOサブシステムの過去の問題を思い起こさせます。 しかし、それがこのようにリモートエンドの何かにどのように影響するかについては、私は本当に考えることができません。そして、レースコンディションはとにかくすべてローカルベースでした。
  
  
  
  • これをテストする1つの方法は、この問題がFab0.9.xおよびpty = True（1.xの現在のデフォルトと一致するため）で発生するかどうかを確認することです。
  
  
• また、ptyに関連している可能性もあります。これが1.0より前の問題であったことを思い出せません。また、ptyをTrueに設定することは、デフォルトの動作における大きな変更の1つでした。 繰り返しになりますが、SSHのrequest-a-ptyサブシステムを使用すると、initスクリプトがこのように動作する理由がわかりません。
  
  
  
  • ここでのテストは、 ssh -t <hostname> <command>を使用して、それでも問題が再現されるかどうかを確認することです。
  
  

2011年7月23日午後7時45分EDT

Jeff Forcier （ bitprophet ）が投稿しました：

apache2ctl自体も、 /usr/sbin/apache2呼び出すラッパーBashスクリプトです。これは、Apachempm-workerのインストール場所にある実際のバイナリ実行可能ファイルへのシンボリックリンクです。 具体的には、通常のstart使用法では、 /usr/sbin/apache2 -k start呼び出します。 以前と同様に、 apache2ctlは、2つの異なるシナリオ（re：戻り値または実行されるセクション）で異なる動作をするようには見えません。

/usr/sbin/apache2のドキュメントは（Apacheのサイトでも）比較的制限されており、apachectlを使用してenv変数を設定する必要があることだけを述べています（正確です- apache2実行するだけでかなりうまくいきます明らかに、これらの変数が設定されていないことに関するエラーがあります。）

apache2ctlがapache2を呼び出す直前に、 envの出力を調べると、ユーザー、グループ、pidfileの場所、言語のいくつかの項目しか得られません。 これらは、成功状況と失敗状況の間で変化しません。 ラッパーのさまざまなソーシングとenvvar設定に、時々変更される何かがあることを期待していましたが、そうではありませんでした。

これまでのところ、これはどこにも役立ちません。 上記のアイデア（pty、ssh）をテストして、そこで何が変わるかを確認します。

2011年7月23日午後8時46分EDT

Jeff Forcier （ bitprophet ）が投稿しました：

pty=False 、はるかにうまく機能するように見えます（＃350のMaxのコメントで示されているように）。 デフォルトのTrue設定では、約5/10回、場合によっては多少の失敗が見られました。 Falseを使用すると、失敗なしで約15回連続して実行しました。 統計学者ではありませんが、それは私にはかなり良いようです。

sshを手動で実行すると、同様の結果が得られます。 ssh -t <host> sudo /etc/init.d/apache2 startは、約50％の時間でApacheの起動にサイレントに失敗します。 -T （強制的にptyなし）と同じで、100％の時間で開始します。

したがって、これはファブリックのせいではありません。 これは、SSHスタイルのpseudo-ttyが機能しているときに、これらのinitスクリプトが誤動作するというより深いものです。

好奇心のためにもう少し深く掘り下げますが、ここでの「解決策」は、この問題が発生したときにpty=Falseを使用することを示す新しいFAQのようです。

2011年7月23日午後8時59分EDT

Jeff Forcier （ bitprophet ）が投稿しました：

残念ながら、この動作を説明するものは何も見つかりませんでした。 上記の調査結果を考えると、FAQは間違いなく進むべき道だと思います。

2011年7月23日午後10時35分EDT

Hugo Garza （hiro2k）の投稿：

昨日これに遭遇したばかりです。このバグが表示されていればよかったのですが、幸運にもpty = Falseを設定してみたところ、うまくいきました。 説明をありがとう、少なくともそれは生地のせいではありません。 今、あなたは本当にこれがなぜ失敗するのか疑問に思っています。

1時27分午後EDTで2011-08-02に

これはbashスクリプトの問題だけではありませんか？ 私のメーリングリストのスレッドを意味します。 それらは、javaとweblogicを開始した単なるbashスクリプトでした。

FWIW、EC2で起動するほとんどすべてのUbuntuマシンでこの恐ろしい動作が発生しています。

また、切り離された画面screen -d -m someBackgroundTask介して起動されたタスクでも再現可能です。

通常はpty=Falseで問題が解決しますが、そうでない場合もあります。

@ yuvadm -pty = Falseで問題が解決しない場合でも、通常のsshコマンド（上記のとおり）を使用して問題を再現できますか？ 私が見た限りでは、これはSSHの問題であり、Fabricの問題ではありませんが、一致しない状況があるかどうかを知っておくとよいでしょう。

それはチェックするのに興味深い角度です、私はそれについてあなたに戻ります...

私はこの問題を再現しました。 クライアントはUbuntu10.04.3 LTS、サーバーは「Ubuntu 8.04.4 LTS（サーバー）」です。
SSHクライアントは「OpenSSH_5.3p1Debian-3ubuntu7、OpenSSL 0.9.8k 2009年3月25日」、sshサーバーは「OpenSSH_4.7p1Debian-8ubuntu1、OpenSSL 0.9.8g 2007年10月19日」です。 生地は「1.3.3ファイナル」です。

問題は、pty = Trueで100％存在し、pty = Falseで消えることです。

他のサーバーに接続している場合、pty = Trueの場合、問題が常に発生するとは限りません。

私の場合、テストのために、次の非常に単純なコマンドを実行しています： "nohup sleep 100> / tmp / xxx 2>＆1

私はこれに噛まれましたが、EC2でしか見られませんでした（Linodeでは見たことがありませんが、100％確信はありません）。 pty = Falseを設定すると、修正されるようです。

ちょうどこの問題に直面しました。
sudoを使用してコマンドを実行したため、tty = Falseを使用できない状況が発生しました。
>& /dev/null < /dev/null &追加は正常に実行されますが、プロセスは開始されませんでした。

コマンド実行行の後にスリープを追加する際の問題を解決しました： nohup java -jar text.jar & sleep 5; exit 0

spodgruskiyに感謝します。

あなたのヒントは私のために働きます。
次のコマンドを使用して、fab tp start stromclusterを作成してみました。

1. run（ 'nohup ./bin/storm nimbus>＆/ dev / null </ dev / null＆'、pty = False）
2. run（ 'nohup ./bin/storm nimbus>＆/ dev / null </ dev / null＆'）
3. run（ "screen -d -m './ bin / storm nimbus'"、pty = False）
4. run（ "|| screen -d -m './ bin / storm nimbus'"）

しかし、それらのどれも機能せず、ニンバスはまったく起動しませんでした。 何が起こったのかわかりません。
とりあえずありがとう。

睡眠トリックの+1

requirettyを備えたシステムで作業する必要があります

sudo（ 'サービスの開始; sleep .5'）そしてすべてが順調です！

'sudo（）'を使用していて、リモートシステムでsudoアクセスに対してRequireTtyが有効になっている場合は、 'set-m;を使用できます。 サービスstart 'は、initスクリプトによって開始されたプロセスにSIGHUPが送信されないようにします。

bashインタラクティブと非インタラクティブの詳細な説明と、それがジョブ制御にどのように影響するかについては、 http：//stackoverflow.com/a/14866774を参照して

私は興味があります、ここでのsshの問題は何ですか？

pty = falseは私のために働きます

これは実際にはSSHの問題ではなく、BASHの非対話型/対話型モードおよびプロセスグループへの信号伝搬に関する微妙な動作です。

以下は、 http： //stackoverflow.com/questions/14679178/why-does-ssh-wait-for-my-subshel​​ls-without-t-and-kill-them-with-t/14866774#14866774およびhttpに基づいてい

pty / tty = false

起動されたbashシェルは、開始されたプロセスのstdout / stderr / stdinに接続し、ソケットに何も接続されておらず、その子が終了するまで実行され続けます。 優れたデーモンプロセスは、子プロセスが終了するのを待たずに、子プロセスをforkしてから終了することを保証します。 このモードでは、SSHによってSIGHUPは子プロセスに送信されません。 これは、それ自体のデーモン化を処理するプロセスを実行するほとんどのスクリプトで正しく機能し、バックグラウンドで実行する必要はないと思います。 initスクリプトが「＆」を使用してプロセスをバックグラウンドで処理する場合、セッションが終了するとSIGHUPがトリガーされるため、バックグラウンド処理されたプロセスがstdinからの読み取りを試みるかどうかが主な問題になる可能性があります。

pty / tty = true *

initスクリプトがプロセスの開始をバックグラウンドで実行する場合、親BASHシェルはSSH接続に終了コードを返します。SSH接続は、子プロセスの終了を待機しておらず、stdoutでブロックされていないため、すぐに終了するように見えます。 / stderr / stdin。 これにより、SIGHUPが親bashシェルプロセスグループに送信されます。これは、bashの非対話型モードでジョブ制御が無効になっているため、起動されたばかりの子プロセスが含まれます。 デーモンプロセスがフォーク時に、またはフォークされたプロセスで新しいプロセスセッションを明示的に開始する場合、デーモンプロセスまたはその子は、終了するBASH親プロセスからSIGHUPを受信しません。 これは、SIGTERMが表示される中断されたジョブとは異なることに注意してください。

これに関する問題は、わずかな競合状態に関係している場合があると思います。 デーモン化の標準的なアプローチ（ http://www.itp.uzh.ch/~dpotter/howto/daemonize ）を見ると、コード内で新しいセッションがフォークされたプロセスによって作成されていることがわかります。親が終了する前に実行するため、上記のランダムな成功/失敗の動作が発生します。 スリープステートメントは、フォークされたプロセスが新しいセッションを作成するのに十分な時間を許可します。そのため、場合によっては機能します。

pty / tty = trueであり、ジョブ制御はbashで明示的に有効になっています

SSHは、bashシェルのstdout / stderr / stdinまたは起動された子プロセスに接続しません。つまり、親bashシェルが要求されたコマンドの実行を終了するとすぐに終了します。 この場合、ジョブ制御が明示的に有効になっていると、バックグラウンドとして「＆」を使用してbashシェルによって起動されたプロセスは、すぐに別のセッションに配置され、BASHセッションの親プロセスが終了したときにSIGHUPシグナルを受信しません（この場合のSSH接続）。

修正する必要があるもの

バックグラウンドプロセス/サービスを使用する場合の特殊なケースとして、run / sudo操作のドキュメントにソリューションを明示的に記載する必要があると思います。 基本的に、「pty = false」を使用するか、それが不可能な場合は、最初のコマンドとしてジョブ制御を明示的に有効にすると、動作は正しくなります。

リンクの更新： http ：

ここで述べたように、fabrickit（ファブリックライブラリのラッパー） https://github.com/HyukjinKwon/fabrickit/commit/cceb8bfb8f960a3ac41b24c64b8358bd6e7a0366

特定の構成や設定がなくても、プログラムをデーモンとして簡単に起動できます。
これはとにかく一種のシェル実行であるため、シェルが実行できることを実行する方法があるはずです。

これを試して：

run("sh -c '((nohup %s > /dev/null 2> /dev/null) & )'" % cmd, pty=False)

私はこれを試しましたが、デーモンとして実行するための追加のプログラミングを実装していなくても、完全に正常に動作します（whileループ内に「Hello」を書き込むプログラムでも正常に動作します）。