У меня есть сценарий Perl, который выполняет некоторые команды на удаленном сервере gerrit через SSH. Он работает на виртуальной машине Debian lenny. В течение нескольких месяцев он выполнялся следующим образом:
./script.pl &>~/script.log &
disown
и все было хорошо. Однако с прошлой пятницы этот скрипт и его дочерние процессы («sh -c ssh ....» и «ssh ...») зависают в какой-то момент именно во время удаленного выполнения команды. «ps x» показывает статус T (sTopped) для всех из них. Отправка SIGCONT на самом деле не помогает. Сразу после этого они получают сигнал SIGSTOP.
Я не вижу такого проводного поведения при интерактивном запуске этого скрипта (теперь он работает на экране без каких-либо проблем).
Я попытался использовать strace, чтобы выяснить, что происходит, но я не могу отловить эту ошибку, поскольку эти сценарии хорошо работают при интерактивном запуске. Я не знаю, кто может отправлять SIGSTOP, и я не знаю, какой именно процесс получает этот сигнал первым. Могу я как-нибудь узнать эту информацию? Как можно исследовать такой вопрос?
P.S. В мои обязанности входит мониторинг и перезапуск (при необходимости) этого скрипта. Я не знаю, какие изменения были внесены ответственными лицами на этом сервере или на удаленном сервере gerrit.
После дополнительных экспериментов со strace (спасибо за комментарий womble) я обнаружил, что мой ssh-процесс получает SIGTTIN, и это вызывает проблему, с которой я столкнулся. Первая ссылка от Google для ssh SIGTTIN проясняет ситуацию: http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch07_04.htm раздел «7.4.5.6. Фон удаленной команды»:
ssh предоставляет параметр командной строки -n, чтобы обойти эту проблему. Он перенаправляет стандартный ввод из / dev / null, что предотвращает блокировку ввода ssh.