зависание ssh процессы, запущенные из сценария

Посмотрите PATTERNS раздел в man ssh_config.

Длинный ответ: Нет, Вы не можете, если Вы не исправляете Ваш ssh поддерживать это.

3
06.10.2013, 03:43
1 ответ

Это походит на состояние состязания и рассмотрение Вашего сценария, я думаю, что вижу где.

От моего понимания у Вас есть сценарий, который содержит следующие 2 строки (среди других):

ssh-keygen -f ~/.ssh/known_hosts -R $IP
ssh-keyscan $IP >> ~/.ssh/known_hosts

И Вы затем запускаете тот сценарий многократно.

Эта последовательность событий может объяснить Вашу проблему:

  1. Один из сценариев открывается ~/.ssh/known_hosts формовать ssh-keygen -R команда. В этой точке ssh-keygen команде считали целый файл в память, таким образом, это может удалить целевую строку.
  2. Другой сценарий только что закончил работать ssh-keyscan и выписывание строки в файл.
  3. Первый сценарий ssh-keygen процесс (тот от шага № 1) начинает выписывать файл, но потому что он считал файл перед законченным шагом № 2, файл, который он выписывает, не содержит строку тот добавленный шаг № 2. Таким образом, строка от шага № 2 вытерта.
  4. Второй сценарий идет для выполнения ssh, только ключ хоста не находится в known_hosts из-за проблемы, упомянутой на шаге № 3. Таким образом, ssh подвешивает желание, чтобы пользователь подтвердил ключ.

Больше детали:
Программы Backgrounded не могут читать из терминала, пытаясь сделать так результаты в той программе, отправляемой SIGTTIN. Однако в Вашем strace, это показывает программу, получая SIGTTOU. Обычно фоновые программы могут записать в терминал без проблемы, однако OpenSSH явно включает названную установку терминала tostop который приводит к этому поведению. Идя еще больше, OpenSSH имеет обработчик сигналов на SIGTTOU (среди других), который приводит к коду OpenSSH, входящему в бесконечный цикл, пока Вы не приносите процесс в forground (в которой точке он может отобразить подсказку, и прекращать сообщаться).

Как Вы хотите пойти о решении, это - другой вопрос.

  • Одно решение состояло бы в том, чтобы добавить блокировку (существует a flock утилита можно использовать), и заблокируйте known_hosts файл перед теми 2 строками, и затем разблокировал после того, как они будут сделаны.
  • Другое решение состояло бы в том, чтобы добавить ssh опцию StrictHostKeyChecking=no. Вы уже побеждаете цель known_hosts файл с теми 2 строками сценария, таким образом, Вы могли бы также просто отключить его в целом.
2
27.01.2020, 21:28
  • 1
    Так как ssh-keygen создает новый временный файл, редактирует и пятится к known_hosts, это создает состояние состязания, когда многократные въезды удалены из known_hosts. я отключил 'StrictHostKeyChecking' в целом, и это решает проблему. спасибо за Ваш ответ. –  rag 06.10.2013, 15:55
  • 2
    @gilles я вернулся Ваши изменения, но сохранил несколько из них. SIGTTOU изменяет Вас сделанный, не точны. Я смог копировать эту проблему о своей системе, и мой терминал не имеет tostop флаг установлен. Что-то еще продолжается здесь. –  Patrick 07.10.2013, 00:28
  • 3
    на выполнении echo cmd&&cmd2 | ssh -o в один из vms и когда известная запись хоста не найдена, ssh пытается записать в терминал, что хост не мог быть проверен. но ssh не является частью группы приоритетного процесса, таким образом, терминал сигнализирует о SIGTTOU., но я не понимаю, почему ssh не распознает, что это не работает в фоновом режиме; я полагаю, что это было бы сказано так сигналом. также я хочу изменить ssh поведение, где оно пытается записать в терминал, но оно не может, и затем программа зависает. я могу только узнать на strace. есть ли путь вокруг для выполнения echo cmd|ssh –  rag 07.10.2013, 10:50
  • 4
    @rag, не совсем уверенный точно, что это, Вы желаете. Если Вы хотите работать cmd на удаленном хосте Вы - более обеспеченное выполнение ssh host "cmd" вместо того, чтобы передать его по каналу в. Если Вы хотите позволить ssh записать в TTY, в то время как фон, перенесите его в a script (script -c 'ssh host "cmd"'). –  Patrick 07.10.2013, 15:11

Теги

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