他のいくつかのサブスクリプトを呼び出すスクリプトがあります。それは後で殺され、これはすべてのサブスクリプトを殺すようです。
ほとんどの場合、これが私が欲しいものです。しかし、私が子供を死なせたくない場合があります。
スクリプトを呼び出すときに&
でバックグラウンド化することで、これを回避できることを覚えていると思います。
誰かがこれを確認できますか?
ここで考慮すべき要素はたくさんあります。記憶からこれらすべての詳細を書いているので、この答えをわずかな塩の粒としてください。 (間違いを見つけた場合は、編集またはコメントで修正してください。)
&
を使用してコマンドのバックグラウンドを設定し、親シェルが正常に終了した場合、バックグラウンドコマンドは引き続き実行されます。
ただし、インタラクティブに実行している場合、「バックグラウンド」コマンドは、端末からの読み取りまたは端末への書き込みを試みるとブロックされます。 (これは、親シェルがまだ実行されているかどうかに関係なく適用されます。)stdout、stdin、およびstderrがリダイレクトされる場合、これは問題になりません。
コマンドをバックグラウンドにして、次に例を示します。 SSHセッションが切断された場合、バックグラウンドコマンドが終了することを期待できます。これはシェルがSIGHUPをそのすべての子プロセスに送信するためだと思いますが、その詳細は100%確実ではありません。
バックグラウンドの後でジョブを(bash組み込みdisown
を使用して)否認した場合、ジョブが終了することはありません。 SSHセッションが終了します。ただし、端末への書き込みまたは端末からの読み取りを試みたときにブロックされるという側面は、引き続き適用されます(インタラクティブセッションの場合)。
サブスクリプトまたはプロセスをバックグラウンドで開始する最も一般的な方法は、それを生成するシェルに何が起こっても影響を受けないように(そして、対話的に開始されたか、スクリプトから開始されたかに関係なく)、です:
Nohup somecommand >/dev/null 2>&1 </dev/null &
これは、コマンドの標準出力または標準エラーへの出力を気にせず、標準入力をフィードする必要がないことを前提としています。
サブスクリプトが親のファイル記述子を継承することに満足している場合(つまり、ターミナルに問題がないか、他の解決策がある場合)、本当に必要なのは次のとおりです。
./some-sub-script &
exit
余談ですが、実行したままにすることを意図したデーモンを作成している場合は、お願い(a)ログを使用し、(b)ログをきれいにローテーションするように注意してください。