私が実行しているコマンドがSSHセッション内にあることを確認しようとしています。通常、$SSH_CONNECTIONこれはプロセスツリーを調べるか見てみるとうまく機能しますsshd。
ただし、screenセッションをローカルで開始してからSSHを介して再接続すると、これは何も機能しません。
セッションが現在接続されているシェルを確認するために再接続された画面セッションにはどのような方法がありますか？
プロセスツリーは次のとおりです。shell(X) --> screen(Y) --> systemd(1)ローカル端末を終了すると、screenセッションの親が再割り当てされる可能性があるため、これは意味があります。
screen -ls他にはなく、(Attached)PIDのみがあり、Y現在接続されている場所に有用なPIDはありません。
リンクプロセスツリーにはshell(A)サブプロセスが含まれていますが、screen(B)PIDYとB。 Unixソケットのもう一方の端を使って画面を見つけようとしましたが、空でした。 （としても確認されているroot）。
これはただ不可能なのでしょうか？
ベストアンサー1
多くの実験の終わりに得られた最終結果は次のとおりです。
シェルが実行されている画面を見つけます。画面プロセスが見つかるまで、 pstree に移動し続けます。
screen_pid=$(pstree -psUA $$ | egrep -o 'screen\([0-9]+\)' | tail -1 | egrep -o '[0-9]+')このプロセスで開いているすべてのファイルを表示します。リストで唯一の/dev/pts/*ファイルを見つけます。
screen_pts=$(lsof -p $screen_pid | grep /dev/pts | awk '{print $NF}')擬似端末を制御する画面プロセスを見つけます。
ps -o pid=,tty= -C screen | grep ${screen_pts/\/dev\/} | awk '{print $1}'そこで、親プロセスはshell/ssh/画面を起動するすべてのものになります。今殻に付いています。
ここには間違いなくいくつかの奇妙な「マイコンピュータ（tm）で動作する」という仮定がありますが、これは一般的な考えです。
信頼性が必要な場合、statwithを使用すると、st_rdevハッキングされた/dev/pts/5 -> pts/5置換が削除されます。同様のものを使用して、major(st_rdev)疑似端末を表す==いくつかの値を使用して開いているファイルのリストをフィルタリングできます。