私は興味深い（少なくとも私にとっては）問題があります。特定のケースでは、孫のプロセスに関する情報を確実かつ移植可能に取得する方法を見つけることができません。私は、そのサブプロセスが子供を産んで死ぬという、ある種の奇妙なケースで働こうとしているアプリケーションAllTrayを持っています。 AllTrayの仕事は、基本的にアプリケーションをタスクトレイにドッキングすることです。タスクトレイはAllTrayが起動するコマンドライン（通常はalltray xtermがxtermを起動し、AllTrayで管理する）として指定されています。POSIXシステムで子プロセスと孫プロセスを確実にトラッキングする方法はありますか？
ほとんどのGUIソフトウェアは、その下でうまく動作します。それは_NET_WM_PID == fork() edの子であるため、そのウィンドウ（またはウィジェット・ライブラリー）には_NET_WM_PIDプロパティーが設定され、すべてが正常に設定されます。ただし、oowriterやK3bなどのKDEで実行するように作成されたソフトウェアを実行する場合など、AllTrayが実行する子プロセスは、シェルスクリプト（OO.oの場合のように）や奇妙な親プロセスが非常に早期に終了するため、fork()およびexec()自体が効果的にバックグラウンドになります。
私は、孫のプロセスIDをプロセステーブルに保存するように、子プロセスを収穫しないようにしていました。その結果、私は祖父母の下位から順番に、上。しかし、私の子プロセスが死んでゾンビに変わると、私の孫プロセスは孤児であるとみなされ、initが採用されます。これは、少なくともLinux 2.6とNetBSDの場合のようです。私はそれがおそらく標準であると推測し、POSIXはそれを指定するようには見えないので、私はその反対を望んでいました。
このアプローチはうまくいかないので、私はLD_PRELOADを使用し、私の子プロセスの呼び出しを傍受してfork()への呼び出しと、親プロセスに情報を渡すことを考えました。しかし、私は理想的なソリューションと同じくらいポータブルではないと心配しています。なぜなら、異なるシステムには、ダイナミックリンカがLD_PRELOADのような仕方で異なるルールがあるからです。少なくともLinuxシステムでは、setuid/setgid GUIアプリケーションでは、ヘルパーライブラリもsetuidでもsetgidでもなく動作しません。一般的に、それは私に悪いアイデアのようなにおいをし、かなりハックを感じる。
だから、私は誰かがこれを行う方法のアイデアを持っていることを望んでいる、またはLD_PRELOADのようなメカニズムに頼るのアイデアは本当に行くではありません、私は（カーネルにパッチを当てるの短い持っている唯一の選択肢である場合発生する）。
Hrm。私はこれを見て、何が起こるか見てみましょう。しかし、アイデアは良いと思う。新しい単一プロセスグループの作成が不十分な理由はありますか？現在、AllTrayは1つのアプリケーションしか管理していません。最終的にはさらに多くの管理を行いますが、1つのpgidがそのプロセスを見付けるだけであれば十分です。 –
これは、ラッパーがKDE <=3 or > 4.3からkdeinitを起動した場合、または既に他のウィンドウが開いている場合などFirefoxが起動していないと想像できます。これらの場合、新しいウィンドウは全く別のツリーのプロセスによって作成されます。 – ephemient
@ephemient私はKDEアプリケーションが奇妙なことをしていることを知っています。私が修正しようとしているケースの1つです。すでにプロセスが稼動しているときには、FFやGNOMEターミナルについてはほとんどできませんが、ユーザーが何を意味するのかについて私は考えています。 –