問題タブ [waitpid]

wait() と waitpid() の違いの 1 つは、waitpid に、まだ終了していない実行中の子がある場合にブロックしないように指示する WNOHANG オプションがあることです。そのような：

waitpid() の代わりに wait() を使用すると、まだ終了していない実行中の子プロセスがある場合に、wait() がブロックされるのを防ぐ方法はありません。ただし、ブロックする可能性がありますが、ここで wait() が正常に機能するかどうかは疑問です。

(C++ モジュールの一部として) fork を呼び出す長時間実行プロセス (node.js) があります。これにより、新しいプロセスが node.js プロセスの子として作成されます。ただし、この子プロセスを待機/待機するものは何もないため、終了後もゾンビのままです。

現在のプロセスを親にせずにプロセスを fork() して、終了時にゾンビ状態のままではなく、クリーンアップすることはできますか?

そうでない場合は、子で waitpid を呼び出さず、いつ終了するかを気にしないことをどうにかして示すことができますか?

これらすべてに失敗しても、waitpid を実行できるネイティブ モジュールを作成/検索できますが、次のようになることを確認する必要があります。

1. 親プロセス (node.js) をブロックしない
2. モジュールの関数が呼び出された後にゾンビを残さない

ありがとう！

私は esh (簡単なシェル) の実装を調べていますが、この場合のシグナルが 22 と 9 であることを理解できません。もっとわかりやすい定数があるのが理想ですが、リストが見つかりません。

Linux で単純なシェルを作成していますが、コマンドをバックグラウンドで実行するのに問題があります。

これまでの私のコードは次のとおりです。

command と argv は、ユーザーから取得したものです。

「&」がコマンドの最後の部分である場合、バックグラウンドでコマンドを実行する必要があります。私はすでにbgのブール変数でそれをチェックしました。しかし、WAITPID() 関数に問題があり、どこに行くのかわかりません。

割り当てのためにシェル パイプの複製に取り組んでいます。パイプラインはすべて機能していましたが (それ以降、パイプライン コードを変更していないため、機能することがわかっています)、パイプラインのあるステップで実行に失敗した場合は、パイプラインを終了する必要がありました。そのコードを実装しているある時点で、パイプラインが予期しない動作を示し始めました。

長さ 2 のパイプラインは正しく機能します。長さが 2 を超えるパイプラインは、次のように失敗します。

1. パイプラインの最初のコマンドが実行されます
2. その直後 (多くの場合、最初のコマンドの実行が終了する前) に、パイプラインの最後のコマンドが終了します。
3. 2 番目のコマンドがハングし、明らかに最初のコマンドから入力を受け取っていません。

以下は、waitpid を使用するセクション コードです (デバッグ コードを除く)。

}

ここで、waitpid セクションが原因であると私が考える理由の核心は次のとおりです。割り当てが要求するいくつかの奇妙な制御フローのため、cmd_status の値を -2 に初期化すると便利であることがわかりました。ロギング関数は、子プロセスの戻りステータスをログに出力します。ファイルには、2 番目の関数の終了ステータスが -2 であることが示されています。これは、もちろん、プログラムで存在ステータスを設定していないことを意味します。パイプラインは、これらのプログラムが実行されるのをまったく待っていないようです。

すなわち

入力 "ls | grep パイプ | wc"

出力：

乱数 n を生成し、n 回ループするプログラムがあります。

反復ごとに、 の値をランダム化し、sleeptimefork を呼び出します。子プロセスは数秒間スリープしsleeptime、インデックス変数の値で終了します。

その後、親は再びループし、各プロセスが終了するのを待ちます。各プロセスが終了するたびに、プロセスの pid と childid をログアウトしようとしていますが、ここで問題が発生しています。pid は順番に出力され、childid は 0 のままです。

私は何を間違っていますか？

免責事項、これは宿題です（リンクはこちら、いつでも消える可能性があります）が、私はすでにほとんどすべてを行っています。私はその一面を理解するのに苦労しています。

次のコードは、10 秒間待機して終了する 2 つの子プロセスを実行します。親はループに座って、子が終了するのを待っています。

コードはこの回答に基づいています: Multiple fork() Concurrency

正しく動作しますが、親ループがプロセッサ時間を消費しています。topコマンドはこれを与えます：

ここで答えは言う：

追加のボーナスとして、waitpid子が実行されている間はループがブロックされるため、待機中にビジー ループは必要ありません。

しかし、私にとってはブロックしません。どうしたの？

次の質問があります: SIGCHLD にシグナルハンドラを使用し、特定の場所で代わりに waitpid(3) を使用できますか?

これが私のシナリオです: ソケットをリッスンするデーモン プロセスを開始します (この時点では、それが TCP ソケットか UNIX ソケットかは関係ありません)。クライアントが接続するたびに、デーモンは要求を処理するために子を fork し、親プロセスは着信接続を受け入れ続けます。リクエストを処理する子は、ある時点でサーバー上でコマンドを実行する必要があります。この例で、次のようなコピーを実行する必要があると仮定しましょう:

そのために、clild は execl(3) (または execve(3) など) を使用して copy コマンドを実行する新しいプロセスを fork します。

コードをより適切に制御するために、コピーを実行している子プロセスの終了ステータスを waitpid(3) でキャッチすることが理想的です。さらに、私のデーモン プロセスは要求を処理するために子プロセスをフォークしているため、ゾンビ プロセスが作成されないように、SIGCHLD のシグナル ハンドラが必要です。

私のコードでは、signal(3) を使用して SIGCHLD のシグナル ハンドラをセットアップし、2 回 fork してプログラムをデーモン化し、ソケットで受信接続をリッスンし、プロセスを fork して、着信する各リクエストと子プロセスのフォークを処理します。コピーを実行する孫プロセスで、waitpid(3) を介して終了ステータスを取得しようとします。

何が起こるかというと、孫プロセスが終了すると、waitpid(3) がアクションを実行し、孫プロセスが成功して終了したにもかかわらず、waitpid(3) が -1 を返す前に、ハンドラによって SIGCHLD が捕捉されます。

私の最初の考えは、追加することでした：

接続しているクライアントを処理するために子プロセスをフォークする直前に、成功しませんでした。SIG_IGN を使用しても機能しませんでした。

私のシナリオを機能させる方法についての提案はありますか?

事前にご協力いただきありがとうございます。

PS。コードが必要な場合は投稿しますが、サイズが大きいため、必要な場合にのみ投稿することにしました。

PS2。私の意図は、私のコードを FreeBSD で使用することですが、私のチェックは Linux で実行されます。

編集[解決済み]:

私が直面していた問題は解決されました。「予期しない」動作は、ある時点でバグがあった私の waitpid(3) 処理コードが原因でした。

したがって、上記の方法を実際に使用して、デーモンのようなプログラムで signal(3) と waitpid(3) を共存させることができます。

この方法が、そのようなことを達成したい人に役立つことを願っています!