Как захватить или историю удара или продержаться x числовые оси от процесса оболочки, работающего на другом tty

Перезапуск сервера человечности или брандмауэра Verizon заставляет его начать работать снова временно?

Для проверки состояния правил брандмауэра использовать

sudo /sbin/iptables -nvL |less

что Вы видите там? Сохраните тот вывод прямо после перезапуска и затем сравните с тем, когда он прекращает работать - некоторый другой процесс унавоживает с Вашими правилами брандмауэра (через crontab, возможно)? Кажется нечетным, но это могло объяснить поведение, которое Вы видите.

6
задан 25 July 2013 в 20:14
3 ответа

Хорошо, я разобрался. На самом деле это довольно полезная вещь, поскольку я могу предвидеть, что она найдет много применений.

  1. открыть сеанс ssh для удаленного хоста. запустить сеанс экрана или tmux с несколькими окнами. Вы можете определить псевдоустройство для каждого окна, набрав «tty». Допустим, у нас есть «/ dev / pts /

    », соответствующие трем оболочкам, которые мы запускаем в сеансе экрана

  2. , определяем pid рассматриваемого процесса bash (тот, для которого вы хотите перенаправить ввод и вывод) . этот процесс в настоящее время связан с терминальным устройством, таким как / dev / tty1

  3. из окна экрана 1, запустите «gdb -p [pid]» и выполните следующие команды в gdb:

    a. p dup2 (open ("/ dev / pts / 2", 0), 0) # изменяет стандартный ввод для целевого процесса

    b. p dup2 (открыть (" Это связано с тем, что операционная система знает, что есть два источника, которые касаются ввода с клавиатуры для / dev / pts / 2, и справедливо распределяет символы, которые вы вводите. первый символ переходит к одному месту назначения, следующий - ко второму месту назначения и т. д. Если у вас было три процесса, чей стандартный ввод был / dev / pts / 3, то вам пришлось бы вводить каждый символ по три раза. Ядро передает входящие символы получателям циклически.

    6. Вы можете обойти вышеуказанное неудобство, временно установив stdin для исходной оболочки Window 2 bash на какое-либо неиспользуемое устройство, например / dev / tty5 или что-то в этом роде. это делает клавиатуру / dev / pts / 2 стандартным вводом только для одного процесса (вместо двух). теперь вы можете вводить команды как обычно (они просто не будут отображаться на экране, в котором вы находитесь, вместо этого они будут отображаться в / dev / pts / 3. )

    7. так как вы набрали 'history', и она была передана целевому процессу, чей стандартный вывод - окно 3, переключитесь в окно 3, чтобы вы могли видеть вывод команды. теперь у вас есть история команд для целевой оболочки bash.

    8. вернувшись к окну 1, снова используйте gdb на [pid], чтобы сбросить стандартные значения in, out, err для целевой оболочки к исходным значениям (/ dev / tty1). И вы также можете вернуть стандартный ввод Window 2 в то состояние, которое должно быть.

    1. Если хотите, вы можете очистить лишние файловые дескрипторы, удалив их с помощью 'exec 3> & -', например, чтобы удалить fd 3

    Обратите внимание, что когда вы запускаете gdb для запущенного процесса, он приостанавливает выполнение процесса так же, как SIGSTOP. Когда вы его «отсоединяете», он возобновляет работу, как в SIGCONT. Это позволяет манипулировать дескрипторами файлов без неблагоприятных последствий.

    Я не пробовал это делать, но вы, вероятно, можете сделать описанное выше еще проще и удобнее для пользователя, открыв оболочку, определив ее tty или pty, временно установив назначенный стандарт оболочки для неиспользуемого устройства, назначив tty / pty как стандартный ввод / вывод для целевой оболочки. Таким образом, вы можете использовать один экран для всего ввода и вывода с целевой оболочкой.

    РЕЗЮМЕ: с помощью описанной выше процедуры, если у вас есть оболочка, к которой у вас есть доступ, вы можете использовать ее в качестве стандартного ввода / вывода для любого другого процесса / оболочки в системе. Это полезно, например, если вы хотите взаимодействовать с оболочкой, запущенной на консоли, но у вас нет физического доступа к хосту (или решения для отключения света).

3
ответ дан 3 December 2019 в 00:36

Вы можете получить эту информацию из / proc / $ {PID} / cmdline .

-1
ответ дан 3 December 2019 в 00:36

Я все еще сталкиваюсь с этой ситуацией полурегулярно и, наконец, придумал несколько более простых способов восстановления команд истории в памяти из моих "осиротевших" сеансов bash:

(примечание: в каждом в примере ниже замените PID на идентификатор процесса потерянного сеанса bash)

Фактически активируйте history -a :

$ gdb -p PID -batch -ex 'call maybe_append_history(get_string_value("HISTFILE"))'

Выгрузите последние 10 записей истории на локальный терминал (pty)

$ gdb -p PID -batch -ex 'call append_history(10, "'$(tty)'")'

Резервное копирование всей истории во временный файл:

$ gdb -p PID -batch -ex 'call write_history("/tmp/history-backup.txt")'

Примечания:

  • Протестировано с помощью bash 4.3 в Ubuntu 16.04.01.
  • В моей системе мне пришлось вызывать с помощью sudo gdb -даже для доступа к моим собственным процессам bash.
  • Если вызов прошел успешно, вы должны увидеть $ 1 = 0 (если вы видите другие значения, они, скорее всего, errno - например, при попытке добавить файл, который еще не существует, вы получите $ 1 = 2 (ENOENT)).
  • Этот подход основан на изучении того, что код bash C делает в ответ на история команда; например: builtins / history.def # L203-L212
2
ответ дан 3 December 2019 в 00:36

Теги

Похожие вопросы