Как мы можем знать, кто в другом конце устройства псевдотерминала?

Если вы просто ищете, кому принадлежит это соединение и откуда оно подключено, команда who будет работать хорошо.

$ who
falsenames   tty8         Jun 13 16:54 (:0)
falsenames   pts/0        Jun 16 11:18 (:0)
falsenames   pts/1        Jun 16 12:59 (:0)
falsenames   pts/2        Jun 16 13:46 (:0)
falsenames   pts/3        Jun 16 14:10 (:0)
falsenames   pts/4        Jun 16 16:41 (:0)

Если вы также хотите знать, что прослушивает это соединение, w покажет это в конце.

$ w
 16:44:09 up 2 days, 23:51,  6 users,  load average: 0.26, 0.98, 1.25
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
falsenames   tty8     :0               Fri16    2days 53:36   0.59s x-session-manager
falsenames   pts/0    :0               11:18    5:25m  1:10   1:10  synergys -a 10.23.8.245 -c .synergy.conf -f -d DEBUG
falsenames   pts/1    :0               12:59    3:44m  0.05s  0.05s bash
falsenames   pts/2    :0               13:46    2:52m  0.11s  0.11s bash
falsenames   pts/3    :0               14:10    2:17   0.07s  0.07s bash
falsenames   pts/4    :0               16:41    1.00s  0.04s  0.00s w

А чтобы получить пиды, ограничьте ps на tty сессию, на которую вы смотрите. Полностью ненавязчивая загрузка.

$ ps -t pts/0 --forest 
  PID TTY          TIME CMD
23808 pts/0    00:00:00 bash
23902 pts/0    00:03:27  \_ synergys

Обратите внимание, это может привести к красной селедке, в зависимости от времени. Но это хорошее место для начала.

$ tty
/dev/pts/4
$ ps -t pts/4 --forest
  PID TTY          TIME CMD
27479 pts/4    00:00:00 bash
 3232 pts/4    00:00:00  \_ ps
27634 pts/4    00:00:00 dbus-launch

Сначала я попытался отследить несколько xterm секунд назад к xterm pid, основываясь на информации, которую я нашел в /proc/locks, но она была потеряна. Я имею в виду, что это работало, я думаю, но в лучшем случае было косвенно - я не до конца понимаю всю информацию, которую предоставляет этот файл, и она соответствовала только тому, что, казалось бы, соответствовало ее содержанию и известным терминальным процессам.

Затем я попробовал посмотреть lsof/strace на активный процесс write/talk между ptys. Раньше я никогда не пользовался ни одной из этих программ, но они, кажется, полагаются на utmp. Если у моего целевого pty не было записи utmp по какой-то причине, они оба отказались признавать её существование. Может быть, есть способ обойти это, но я был достаточно растерян, чтобы отказаться от этого.

Я пробовал некоторое открытие udevadm с 136 и 128 узлами устройства с большим числом, как рекламировалось для pts и ptm соответственно в /proc/tty/drivers, но мне также не хватало никакого очень полезного опыта работы с этим инструментом, и опять-таки не оказалось ничего существенного. Интересно, однако, что диапазон :min для обоих типов устройств был перечислен в ошеломляющем списке 0-1048575.

Только после того, как я пересмотрел этот документ ядра , я начал думать о проблеме с точки зрения монтирования . Я читал это несколько раз до этого, но когда продолжающиеся исследования в этой строке привели меня к этому этому 2012 /dev/pts патчсету , у меня возникла идея:

sudo fuser -v /dev/ptmx

Я подумал , что я обычно использую, чтобы ассоциировать процессы с mount? И конечно:

                     USER        PID ACCESS COMMAND
/dev/ptmx:           root      410   F.... kmscon
                     mikeserv  710   F.... 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

Он печатает $$ num \0 null bytes to each pty и сверяет io каждого мастер-процесса с предыдущей проверкой. Если разница составляет $$, то pid ассоциируется с pty. Это в основном работает. Я имею в виду, для меня это возвращает:

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

Что верно, но, очевидно, немного радужно. Я имею в виду, что если бы один из тех, кто читал кучу данных в то время, он, вероятно, пропустил бы. Я пытаюсь понять, как изменить режимы stty на другой pty, чтобы сначала послать стоповый бит или что-то в этом роде, чтобы я мог это исправить.

У меня была та же проблема с qemu, и я наконец нашел очень плохое решение (но все же решение): разбор памяти процесса.

Это работает, потому что я знаю, что qemu хранит удаленные точки в строке с определенным форматом и размещается в куче. Возможно, он может работать и в других ситуациях с некоторыми изменениями и повторным использованием pid из вывода фьюзера (проверьте другой ответ).

Код адаптирован из здесь .

#! /usr/bin/env python

import sys
pid = sys.argv[1]

import re
maps_file = open("/proc/" + pid + "/maps", 'r')
mem_file = open("/proc/" + pid + "/mem", 'r', 0)
for line in maps_file.readlines():
    # You may want to remove the 'heap' part to search all RAM
    m = re.match(r'([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r]).*\[heap\]', line)
    if m and m.group(3) == 'r':
        start = int(m.group(1), 16)
        end = int(m.group(2), 16)
        mem_file.seek(start)
        chunk = mem_file.read(end - start)
        # You may want to adapt this one to reduce false matches
        idx = chunk.find("/dev/pts/")
        if idx != -1:
            end = chunk.find("\0", idx)
            print chunk[idx:end]
maps_file.close()
mem_file.close()