.xsessionファイルが最後のプロセスが前景にあると予想する理由を理解しようとしています。それ以外の場合は、X11セッションを停止する必要があります。
小さなスタンドアロンスクリプトがあります。実行すると、「less」が背景にあるためすぐに終了します。
$ ls -l total 4
-rwxr-xr-x 1 user user 17 Feb 28 21:17 a
-rw-r--r-- 1 user user 0 Feb 28 20:22 b
$ cat a
less b &
echo $!
私は「少ない」ツールが主にフォアグラウンドで対話することを理解しています。どうするかはわかりませんが、もはやフォアグラウンドで実行されず、入力を受け取ることができないか、ユーザーにいくつかの出力を表示できないことを認識したようです。したがって、実行はもはや役に立たないので終了します。それとも正確に何が起こりましたか？
ウィンドウマネージャをバックグラウンドに置くと、なぜ終了しますか？フォアグラウンドで実行されず、Xサーバーを介してキーボード/マウス入力を受け取ることができず、もはや役に立たないので終了しますか？
答え1
これは実際には全く異なる2つの現象です。
lessバックグラウンドにあるかどうかはそれ自身をチェックしません（ターミナルと対話するプログラムの場合は一般的です）。プロセス 1 のプロセスは、カーネルの汎用端末ドライバによって追跡されます。展望。フォアグラウンドプロセス（より正確にはプロセスグループ）は1つしかありません。シェルはシステムコールを行います（tcsetpgrp）fg組み込み関数を使用してプロセスを前景にインポートするとき。このシステムコールは、指定されたプロセスをフォアグラウンドプロセスにします。
プロセスがターミナル2からデータを読み取ろうとすると、ターミナルドライバはプロセスが前景にない場合にプロセスにSIGTTIN信号を送信します。デフォルトでは、この信号はプロセスを停止します（例：SIGSTOP）。同様に、制御端末への書き込みを試みるバックグラウンドプロセスは、SIGTTOUを受信する。ほとんどのシェルは、このような場合に通常メッセージを表示します[1] + suspended (tty output) less myfile。
端末の詳細については、端末の説明を参照してください。汎用端末インターフェースPOSIX規格で。 （この本は読みやすい本ではありません。ほとんどのユーザーよりもはるかに多くのコンテンツが含まれており、より多くのプログラマーが知っておく必要があります。）
ウィンドウマネージャは端末と対話しないため、端末のバックグラウンドおよびフォアグラウンドプロセスの概念は適用されません。 X セッションが終了すると、X Server 3 も終了します。ウィンドウマネージャを呼び出すスクリプトは、セッションで何をすべきかを示します。ウィンドウマネージャをバックグラウンドに置き、ウィンドウマネージャを待たずにセッションスクリプトを終了させると、セッションは予想より早く終了します。
¹何プロセスグループ、実際には（パイプに似ていますが）ここでは詳しく説明する必要はありません。
²該当制御端子実際に。
³アプリケーションでウィンドウを描く、入力を読み取るなどのコマンドを実行するGUIのバックエンド部分。
答え2
ウィンドウマネージャが前景、背景、または任意の種類のタスク制御下にある必要はありません。必要ない場合は、ウィンドウマネージャを実行する必要さえありません！
唯一重要なのは、.xsessionスクリプトが終了するとセッションも終了することです。終了すると、.xsessionXサーバー自体も終了し、まだ接続されているすべてのプロセスは強制終了されます。
したがって、.xsessionスクリプトは通常、スクリプトが最後に実行したジョブがセッションに関連する長時間の実行プロセスになるように作成されます。これはウィンドウマネージャまたはセッションマネージャです（現代の高度なデスクトップ環境でより一般的です）。プロセスは、exec実行中のシェルを置き換えるように実行されるか、シェル.xsessionがそれを待つようにフォアグラウンドプロセスとして実行されます。どちらの方法でもプロセスが終了すると、セッションは終了します。
サンプルシェルスクリプトはlessバックグラウンドで開始され、すぐに終了します。バックグラウンドプロセスを待ちません。終了するかどうかにかかわらずless終了します。lessバックグラウンドで実行することはできますが、シェルスクリプトをどのように実行しても気付かないでしょう。.xsession同じ方法で作成されたスクリプトでも同じ問題が発生します。