Почему Вам нужен screen/tmux для поддерживания удаленной программы в рабочем состоянии

Можно использовать OpenSSL для генерации случайного пароля (16 символов, в этом случае):

# 1000 bytes should be enough to give us 16 alphanumeric ones
p=$(openssl rand 1000 | strings | grep -io [[:alnum:]] | head -n 16 | tr -d '\n')

Затем подайте хешированный пароль к useradd или usermod

# omit the "-1" if you want traditional crypt()
usermod -p $(openssl passwd -1 "$p") 

Кредит, где должный: поколение пароля адаптировано от похожего метода, который использует /dev/urandom вместо openssl.

1
09.12.2013, 23:02
2 ответа

С точки зрения операционной системы каждая запускающая программа является процессом. То, когда ядро будет сделано, инициализируя его, запустит один процесс, главным образом init. Является ли это SYSV init, или systemd не важен для этого обсуждения, один процесс запускается. Любая программа запущена другим процессом. Это создает отношения между процессами, стартовым процессом (иначе "родитель") и запущенным процессом (иначе "ребенок"). Ядро знает об этих отношениях.

Когда процесс выходит в Linux/Unix, ядро отправляет во все его дочерние процессы сигнал номер 15 (SIGTERM). Это может быть поймано процессом, и процесс должен сделать то, что это должно сделать для выхода безопасным способом. Можно знать, также знают сигнал номер 9 (SIGKILL). Этот сигнал не может быть пойман процессом: ядро останавливает процесс отдельно.

Посмотрите это pstree:

init─┬─acpid
     ├─atd
     ├─cron
     ├─dbus-daemon
     ├─dhclient
     ├─dhcpd
     ├─exim4
     ├─6*[getty]
     ├─lwresd───6*[{lwresd}]
     ├─named───6*[{named}]
     ├─nmbd
     ├─portmap
     ├─rpc.statd
     ├─rsyslogd───2*[{rsyslogd}]
     ├─smbd───2*[smbd]
     ├─sshd───sshd───bash───screen───screen───bash───pstree
     └─udevd───2*[udevd]

Вы видите это pstree дочерний процесс bash, и bash дочерний процесс screen. Когда я выхожу из системы от машины, bash после sshd выходы и ядро отправляют сигнал 15 в дочерний процесс screen. НО, screen не реагирует на это. Так screenновый родительский процесс является теперь процессом номер 1 (init). Посмотрите в этом pstree:

init─┬─acpid
     ├─atd
     ├─cron
     ├─dbus-daemon
     ├─dhclient
     ├─dhcpd
     ├─exim4
     ├─6*[getty]
     ├─lwresd───6*[{lwresd}]
     ├─named───6*[{named}]
     ├─nmbd
     ├─portmap
     ├─rpc.statd
     ├─rsyslogd───3*[{rsyslogd}]
     ├─screen───bash
     ├─smbd───2*[smbd]
     ├─sshd───sshd───bash───pstree
     └─udevd───2*[udevd]

На самом деле это - то, что происходит, когда Вы отсоединяетесь screen (ctrl+a - d). Так все подпроцессы screen продолжайте бегать за разъединением или отсоединением от screen. Когда Вы выполняете процесс без screen или tmux, это получит сигнал SIGTERM.

3
27.01.2020, 23:13
  • 1
    Нет, ядро не отправляет SIGTERM детям процесса, когда это умирает. Это может отправить SIGHUP при некоторых обстоятельствах (и это имеет отношение к обработке сессии, не отношениям отцов и детей). Это не видит, какой SIGILL имеет отношение ко всему это. –  Stéphane Chazelas 09.12.2013, 23:44
  • 2
    При Принятии этого, поскольку это отвечает, почему, но было бы хорошо, если кто-то исправит ошибку. информации –  The Unfun Cat 10.12.2013, 09:10

Необходимо использовать команду nohup. Объяснение дано здесь. В основном это отсоединяет программу, которую Вы запускаете от своего терминального сеанса, это закрывается, программа не умирает со своим родителем. tmux и экран также отсоединяют программы, которые они запускают именно поэтому, Вы получаете то же поведение.

4
27.01.2020, 23:13

Теги

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