孤立プロセスグループとターミナルセッションの概要

孤立プロセス：親プロセスが終了したプロセス。孤立プロセスはinitプロセス「Adoption」によって継承され、initプロセスIDは1であるため、採用された孤立プロセスの親プロセスは1に更新されます。

孤立したプロセスグループ：プロセスグループ内のすべてのプロセスの親プロセスは、プロセスグループのプロセス、またはプロセスグループが配置されているセッション内のプロセスのいずれかです。プロセスグループが孤立したプロセスグループではないという条件は、グループ内に1つのプロセスがあり、その親プロセスが同じセッションに属する別のグループにあることです。

GNUは、なぜ孤立したプロセスグループという概念、その端末が解放され、新しいセッションを確立できるのかを説明しています（実際、他のユーザーが端末にログインする可能性があります）。問題を回避するために、セッションリーダーが終了した後も実行を継続しているプロセスグループは、孤立したプロセスグループとしてマークされます。プログラムがこのシグナルを無視するか、それに対するハンドラを確立すると、その制御プロセスの後でも、孤立したプロセスグループのように実行を継続できます。終了しますが、それでも端末にアクセスすることはできません。

端末制御プロセス（つまり、セッションの最初のプロセス）が終了すると、その端末を使用して新しいセッションを確立できます。これにより、古いセッション内の任意のプロセス（1つ以上のプロセスグループの集合）が再び端末にアクセスできるという問題が生じる可能性があります。このような問題を防ぐために、孤立したプロセスグループという概念があります。プロセスが孤立したプロセスグループで構成されている場合、posix.1では孤立したプロセスグループ内のプロセスにSIGHUP（中断）シグナルを送信する必要があります。それが別々に扱われるなら、中断されたプロセスは実行を続けることができます。

以下はネットワークからの抜粋です。

端末の問題にはいくつかの概念が含まれます。つまり、プロセスグループ、セッション、および操作です。これらについては、以下で別に説明します。セッションは、実行内容に応じてプロセスグループに編成された一連のプロセスで構成され、セッション内のすべてのプロセスはセッションリーダープロセスの子孫である必要があるため、これらのプロセスがセッションのリーダーになります。プロセスが直接または間接的に開かれることによってのみ、プロセスがセッションリーダープロセスの視界内にあることが保証され、同時に孤立プロセスグループはセッションリーダープロセスによって制御されなくなります。宿題：端末は1つしかありませんが、同時に実行すること、または少なくとも時分割で実行することが多いので、別の操作を実行する前に1つの操作を実行することはできません。結局、プロセスの開始後、プロセスは端末を独占し、シェルはそれをフォアグラウンドプロセスグループプロセスとして設定します。これはジョブの機能です。たとえば、コマンドの後に&記号を追加するだけです。たとえば、xを実行したいと入力します。x&シェルの結果は次のようになります。[1] 1234 1234はプロセスです。 Pid、および1はジョブのIDです。したがって、xは端末を占有しません。シェルは他のプロセスまたはジョブを開始できます。たとえば、ジョブ2を開始します。[2] 4321ジョブ1は端末を使用する必要があると思います何らかの情報を入力してから：fg％1を使用してジョブ1をフォアグラウンドにします（現在ジョブ1には1つのプロセスしかありません）。フォアグラウンドに置かれたジョブをバックグラウンドに入れる方法は？ SIGSTOPシグナルを使用して、端末をフォアグラウンドで使用するプロセスを停止するだけで、プロセスはプロセスグループを占有している端末を解放します。1つのジョブはプロセスグループです。別のプロセスはプロセスグループを独占したり、同じセッションの別のセッションに参加できます。プロセスグループは、同じプロセスグループ内のすべてのプロセスがセッションの子孫でなければならないという条件を満たす必要があります。いわゆるプロセスグループは、作業をまとめたり、同じ種類のタスクをまとめたりすることです。制御端末：セッションの作成者は、標準入力を受け入れ、シェルが理解できる制御ショートカットを送信し、ジョブを作成し、セッションヘッダープロセスによって提供されるジョブ制御機能を使用できる制御端末を申請する権利を持ちます。制御端末はセッションヘッダプロセスでしか作成できず、制御端末は排他的であり、1つのプロセスが1つの端末を制御端末と見なす限り、他​​のプロセスはそれが誰であるかに関係なくこれを行うことができません。 （！noctty&<>>シグナル>リーダー&>>シグナル> tty&&>> session == 0）{task_lock（current）; current-> signal-> tty = tty; task_unlock（current）; current-> signal-> tty_old_pgrp = 0; tty-> session = current-> signal-> session; //set sessiontty - > pgrp = process_group（current）;}他のプロセスは制御端末を申請する権限がないことがわかります。この制御端末は通常誰に使用されますか？なぜなら、たとえ彼が疑わしいとしても、後に彼に属する子供たちは疑わしいので、ヘッドの適用のためのターミナルは子供たちのためである。複数のプロセスグループに分割され、1つのグループがフォアグラウンドプロセスグループとして指定され、このフォアグラウンドプロセスグループのプロセスだけが制御端末を使用できます。 bashは通常、セッションリーダーとして存在し、実行されたコマンドのプロセスグループを作成し、実行されるコマンドを受け入れると、そのプロセスをフォアグラウンドプロセスグループとして設定します。このコマンドはジョブを作成し、それをバックグラウンドプロセスグループとして設定します。それからフロントデスクを担当するユーザーが自分自身を強打します。バックグラウンドプロセスでは端末を使用できませんgetcharなどの関数を使用してプロセスを実行するために&を使用すると、SIGTTINシグナルを受信しますが、fgコマンドを使用してそのようなプロセスを前面に表示できます。制御プロセス：もちろん、最初の制御プロセスはセッションの先頭プロセスであり、さらにセッションリーダーは端末を介して他のプロセスを制御することしかできません、いわゆる制御はプロセス間のメモリ操作の代わりにシグナルを送信することです。コミュニケーションの方法つまり、いわゆる制御プロセスは、制御端末に適用するプロセスです。 （運用管理も同様）孤立プロセスグループ：孤立プロセスがあり、孤立プロセスグループの概念もあります。なぜこの概念を導入し、この概念を導入するためにOSの実装者が何かをする必要があるのでしょうか。まず2つの前提を見てください。まず、posixはセッションの概念を使用してユーザーのログインとユーザーのログイン後の操作を記述し、次にジョブの概念を使用してさまざまな操作の内容を記述します。操作の1つの特定の操作、2番目に、Unixは最初にすべてのプロセスをツリー形式に編成したので、各プロセスを追跡し管理するのが容易になります（人間の政治社会もツリーのような構造です。 、二院制など）。以上の2つの前提で、すべてが管理者であること、つまりログインしているユーザーのセキュリティがすべてであること、つまり、ログインしているユーザーのジョブを次のログインユーザーによって制御することはできません。同じ名前も受け入れられないので、いわゆる孤立したプロセスグループは、それを作成したセッションコントロール、セッションアイライナーを離れるプロセスグループ、Unixでプロセスを制御する方法、自分のアイライナーにあるかどうかを証明する方法、ツリー構造は、それ自体が根付いているサブツリー内のプロセスがアイライナー内のプロセスである限り、そのプロセスは保護されて動作する権利を持ち、他のブランチ上のプロセスは原則としてアンタッチャブルです（私はまた、ウィンドウのリモートスレッドの作成についても話したいのですが、その複雑なトークンメカニズム、そうでなければウィンドウズのファンは納得できないので、言わないでください、当然のことです。 "フォーク"はもちろん自分のアイライナーの中で、自分自身の枝を形成し、一般的にセッションはログインユーザーで始まります。 2回目のログイン後、ユーザーがログアウトしない限り、端末のシェルで実行されたすべての非デーモンプロセスはシェルの子孫であるため、すべてシェルのアイライナーでセッションを形成し、セッションは終了します。セッションリーダーの死（注：プロセスグループの終了はリーダープロセスの終了とは無関係です）。シェルが端末を終了した後のシナリオを考えてみると、規則によると、端末上のすべてのプロセスが他のプロセスに渡され、ほとんどの場合initプロセスであり、その後別のユーザーが端末にログインするか前のプロセスを知っています。ユーザーキーにログインするのをよく知らない人が端末にログインした場合もちろん、起動されたシェルに対して新しいセッションが作成されます前回ログインしたユーザーがログアウトしたため、今ログインしたユーザーは前のユーザーのプロセスグループによるものです。孤立したプロセスグループのメンバーは、安全に実行を続けるか、またはシェルが終了したときにシェルから送信されたSIGHUPシグナルによって強制終了されます。 POSIXのルールはアイアンディシプリンであり、カーネルであろうとシェルであろうとUNIX /Linuxの実装はディシプリンベースのアプローチであり、アイアンディシプリンはセッションに基づいていること、つまり他のセッションで動作できないことを要求します。プロセスグループ、つまりfgやbgのようなコマンドは孤立したプロセスを操作することができません。読み取り/書き込み端末が停止したためにバックグラウンドプロセスグループがSIGSTOPシグナルによって停止し、孤立プロセスグループのメンバーになった場合はどうなりますか？ ps -xjがそれを見つけて手動でSIGCONTを送ったとしても、他のセッションのジョブ制御コマンドはそれを操作することはできません端末を使用することはできません。フォアグラウンドプロセスグループのプロセスは端末を使用することができます。そのため、シェルが終了する限り、セッション内のすべてのプロセスを強制終了するのが最善の方法です。SIGHUPの本来の目的はこれですが、完全に無視することもできます。このシグナルに対する応答を定義してください。 POSIXの基本的な制限は、セッションIDは保護された基本単位であるため設定できないが、プロセスグループのIDは設定でき、結局のところ不可能なジョブしか識別できず、最後のプロセスのPIDは設定できないということです。これはプロセスの内部プロパティなので、ツリー構造構造の重要な属性を形成します。 POSIXは孤立したプロセスグループを定義します。プロセスを持たないプロセスの親プロセスは同じセッションに属しますが、異なるプロセスグループに属します。デーモン：デーモンはいくつかのことをする必要があります：1.子プロセスのフォーク：bashはプログラムを実行するときにforkとexecの間のフォアグラウンド・プロセス・グループ・プロセスとしてプログラムを設定するので、その後フォークはセットアップされません。その場合、子プロセスはバックグラウンドプロセスになり、排他的なプロセスグループはなく、子プロセスは親プロセスのプロセスグループに属します。 2. setsidを呼び出して新しいセッションを開始し、新しいプロセスグループを開始します。これが新しいセッションの先頭になります。 3.子プロセスを再度フォークします。これにより、最初のフォークの子プロセスが端末を制御するために再適用されるのを回避できます。結局、それはセッションリーダーです。 4.端末がないため、すべてのファイル記述子を閉じます。特に端末関連の記述子0、1、2などを閉じます。 5…。