☰

疑似端末装置の反対側に誰がいるのか、どうすればわかりますか？

tag-icon • tag-icon terminal-emulator open-files pty
疑似端末装置の反対側に誰がいるのか、どうすればわかりますか？

私が次のことをしたら：

echo foo > /dev/pts/12

一部のプロセスはfoo\nファイル記述子からマスターにそれを読み込みます。

そのプロセスが何であるかを理解する方法はありますか？

言い換えれば、どのxterm/sshd/script/screen/tmux/expect/socat...が反対側にあるのか、どうすればわかりますか/dev/pts/12？

lsof /dev/ptmxptyのマスター側にファイル記述子があるプロセスを知らせます。プロセス自体はptsname()（TIOCGPTNioctl）を使用して独自のfdに基づいてマスターデバイスを見つけることができるので、次のことができます。

gdb --batch --pid "$the_pid" -ex "print ptsname($the_fd)"

このマップは返された各pid / fdに対して作成されていますが、lsofこの情報を取得するより直接的で信頼性が高く、侵害の少ない方法はありますか？

ベストアンサー1

最初は見つけた情報に基づいてpidを追跡してみましたが、緩んでxtermいました。私の言葉は、うまくいくと思いますが、せいぜい状況に応じたものです。そのファイルが提供するすべての情報を完全に理解しておらず、その内容と既知の端末プロセスの間で一致しているように見えるものだけが一致します。xterm/proc/locks

それから、pty間のアクティブlsof/straceプロセスを観察しようとしています。write/talk私は以前に2つのプログラムを実際に使用したことがありませんが、それに依存しているようです。何らかの理由でutmp私のターゲットptyにエントリがない場合、どちらもその存在を認めません。utmpたぶんこの問題を解決する方法があるかもしれませんが、混乱して諦めました。

私はudevadmそれぞれと広告された136と128のマスターデバイスノードを使用していくつかの発見を試みptsましptmたが、/proc/tty/driversそのツールの非常に有用な経験が不足しており、もう一度実用的なコンテンツを見つけることができませんでした。しかし、興味深いことに、両方:minのデバイスタイプが驚くべき価格でリストされていることがわかりました0-1048575。

これをもう一度見るまでこのカーネル文書しかし、私はこの問題をsの観点から考え始めましたmount。私は以前この内容を何度も読んでいましたが、その分野の継続的な研究を通してこれを発見しました。この2012/dev/ptsパッチセット私は考えがあります：

sudo fuser -v /dev/ptmx

私の考えではプロセスをにリンクするには通常何を使用しますかmount？本当に：

                     USER        PID ACCESS COMMAND
/dev/ptmx:           root      410   F.... kmscon
                     mikeserv  710   F.... terminology

したがって、この情報を使用して次の操作を実行できますterminology。

sudo sh -c '${cmd:=grep rchar /proc/410/io} && printf 1 >/dev/pts/0 && $cmd'
###OUTPUT###
rchar: 667991010
rchar: 667991011

ご覧のとおり、いくつかの明示的なテストでこれらのプロセスを作成して、任意のptyの基本プロセスを非常に安定して出力できます。ソケットに関しては、デバッガを使用するよりもその方向からアクセスすることが可能だと確信していますsocatが、まだ方法を見つけることができませんでした。しかし、ssあなたが私よりもよく知っていれば役に立つと思います。

sudo sh -c 'ss -oep | grep "$(printf "pid=%s\n" $(fuser /dev/ptmx))"'

だから実際に設定のためにもう少し明示的なテストをしました。

sudo sh <<\CMD
    chkio() {
        read io io <$1
        dd bs=1 count=$$ </dev/zero >$2 2>/dev/null
        return $((($(read io io <$1; echo $io)-io)!=$$))
    }
    for pts in /dev/pts/[0-9]* ; do
        for ptm in $(fuser /dev/ptmx 2>/dev/null)
            do chkio /proc/$ptm/io $pts && break
        done && set -- "$@" "$ptm owns $pts"
    done
    printf %s\\n "$@"
 CMD

各ptyに$$num nullバイトを印刷し\0、前の確認と比較して各基本プロセスのioを確認します。それ以外の場合は、$$pidをptyに関連付けます。これ最大働く私の言葉は、私には次のように返されます。

410 owns /dev/pts/0
410 owns /dev/pts/1
710 owns /dev/pts/2

正しい言葉ですが、明らかに少し不自然です。私の言うことは、それらの1つがその時点で大量のデータを読んでいる場合、それを見逃す可能性があるということです。stty問題を解決するために、ストップビットが最初に送信されるように他のptyでモードを変更する方法を見つけようとしています。

おすすめ記事