Перезапуск сервера человечности или брандмауэра Verizon заставляет его начать работать снова временно?
Для проверки состояния правил брандмауэра использовать
sudo /sbin/iptables -nvL |less
что Вы видите там? Сохраните тот вывод прямо после перезапуска и затем сравните с тем, когда он прекращает работать - некоторый другой процесс унавоживает с Вашими правилами брандмауэра (через crontab, возможно)? Кажется нечетным, но это могло объяснить поведение, которое Вы видите.
Хорошо, я разобрался. На самом деле это довольно полезная вещь, поскольку я могу предвидеть, что она найдет много применений.
открыть сеанс ssh для удаленного хоста. запустить сеанс экрана или tmux с несколькими окнами. Вы можете определить псевдоустройство для каждого окна, набрав «tty». Допустим, у нас есть «/ dev / pts /
», соответствующие трем оболочкам, которые мы запускаем в сеансе экрана
, определяем pid рассматриваемого процесса bash (тот, для которого вы хотите перенаправить ввод и вывод) . этот процесс в настоящее время связан с терминальным устройством, таким как / dev / tty1
из окна экрана 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 в то состояние, которое должно быть.
Обратите внимание, что когда вы запускаете gdb для запущенного процесса, он приостанавливает выполнение процесса так же, как SIGSTOP. Когда вы его «отсоединяете», он возобновляет работу, как в SIGCONT. Это позволяет манипулировать дескрипторами файлов без неблагоприятных последствий.
Я не пробовал это делать, но вы, вероятно, можете сделать описанное выше еще проще и удобнее для пользователя, открыв оболочку, определив ее tty или pty, временно установив назначенный стандарт оболочки для неиспользуемого устройства, назначив tty / pty как стандартный ввод / вывод для целевой оболочки. Таким образом, вы можете использовать один экран для всего ввода и вывода с целевой оболочкой.
РЕЗЮМЕ: с помощью описанной выше процедуры, если у вас есть оболочка, к которой у вас есть доступ, вы можете использовать ее в качестве стандартного ввода / вывода для любого другого процесса / оболочки в системе. Это полезно, например, если вы хотите взаимодействовать с оболочкой, запущенной на консоли, но у вас нет физического доступа к хосту (или решения для отключения света).
Я все еще сталкиваюсь с этой ситуацией полурегулярно и, наконец, придумал несколько более простых способов восстановления команд истории в памяти из моих "осиротевших" сеансов bash:
(примечание: в каждом в примере ниже замените PID
на идентификатор процесса потерянного сеанса bash)
history -a
: $ gdb -p PID -batch -ex 'call maybe_append_history(get_string_value("HISTFILE"))'
$ gdb -p PID -batch -ex 'call append_history(10, "'$(tty)'")'
$ gdb -p PID -batch -ex 'call write_history("/tmp/history-backup.txt")'
Примечания:
sudo gdb
-даже для доступа к моим собственным процессам bash. $ 1 = 0
(если вы видите другие значения, они, скорее всего, errno
- например, при попытке добавить файл, который еще не существует, вы получите $ 1 = 2
(ENOENT)). история
команда; например: builtins / history.def # L203-L212