Вопросы Теги

Регистрация экрана на основе заголовка

SIGKILL никогда не перестает убить запущенный процесс, вот в чем суть. Существуют и другие сигналы, позволяющие приложению отреагировать.

По умолчанию SIGINT, SIGTERM, SIGQUIT и SIGHUP уничтожают программу. Однако приложениям разрешено устанавливать обработчики для этих сигналов. Таким образом, фактическое поведение приложений, когда они получают эти сигналы, является вопросом соглашения (которому каждое приложение может следовать, а может и не следовать), а не конструкции системы.

SIGINT - самый «слабый» из всех. Его обычное значение - «прекратите то, что вы делаете прямо сейчас, и ждите дальнейших действий пользователя». Это сигнал, генерируемый Ctrl + C в терминале. Неинтерактивные программы обычно воспринимают это как SIGTERM.

SIGTERM - это «нормальный» сигнал уничтожения. Он сообщает приложению, что нужно завершить работу без ошибок. Приложению может потребоваться время, чтобы сохранить свое состояние, освободить ресурсы, такие как временные файлы, которые в противном случае остались бы, и т. Д. Приложение, которое не хочет, чтобы его прерывали во время критического приложения, может некоторое время игнорировать SIGTERM.

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

SIGQUIT - самый резкий из игнорируемых сигналов. Он предназначен для использования, когда приложение ведет себя некорректно и его необходимо убить сейчас, и по умолчанию он традиционно оставлял файл дампа ядра (современные системы, где большинство пользователей не знают, что такое файл ядра, как правило, не производить их по умолчанию). Приложения могут устанавливать обработчик, но должны делать очень мало (в частности, не сохранять какое-либо состояние), потому что намерение SIGQUIT должно использоваться, когда что-то серьезно не так.

0
24.09.2018, 23:13
2 ответа

Я не думаю, что для этого есть --другой вариант, кроме просмотра списка процессов:

screen -r $(pgrep -f '\<SCREEN.* -t name\>')

В *BSD нужно что-то другое:

screen -r $(pgrep -t- -f '\<screen.* -t name\>')

Параметр -t-параметра pgrepуказывает, что он должен соответствовать только процессам без управляющего терминала, в этом случае только внутренний процесс screen, а не первый подключенный дисплей(screenизменяет argv[0]внутренний процесс на "SCREEN"везде, но в *BSD изменения в строках argvне отражаются в списке процессов, как в Linux ).

Во FreeBSD также может потребоваться опция -a(«также сопоставлять предков вызывающего процесса» ). К сожалению, pgrep -t-не поддерживается в Linux, а pgrep -aделает что-то совершенно другое.

Итак, поместив все это в функцию:

# usage tscreen title [args...]
tscreen(){
    title=$1; shift
    screen -r $(
      pgrep -f "\\<SCREEN.* -t $title\\>" ||
      pgrep -t- -f "\\<screen.* -t $title\\>" ||
      pgrep -at- -if "\\<screen.* -t $title\\>" ||
      echo "title=$title"
    ) "$@"
}
2
28.01.2020, 02:23

Все, что вам нужно сделать, это использовать имя сеанса в качестве аргумента в командной строке:

screen -r SESSIONNAME

Если у вас несколько экранов с одним и тем же именем сеанса, вам также потребуется указать PID, например:

[jenny@sameen ~]$ screen -r test1
There are several suitable screens on:
    23669.test1 (Detached)
    23594.test1 (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
[jenny@sameen ~]$ screen -r 23669.test1

Это подтверждено на экране 4.01.00devel в RHEL7 и 4.04.00 в BSD.

1
28.01.2020, 02:23

Теги

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