Отказ от ответственности: я немного новичок в сообществе, будьте осторожны :)
У меня проблема с SSH, которую я просто не могу объяснить. В качестве некоторой предыстории, вот проблема, которую я решаю:
В среде существует несколько разрозненных служб Java, которые необходимо развернуть через общий интерфейс. Регистрация этих служб должна быть направлена в средство системного журнала. Общий интерфейс должен быть доступен через командную строку и через графический интерфейс Jenkins.
Я начал замечать проблемы, когда добавил перенаправление в системный журнал. Если я удалю перенаправление системного журнала, все будет работать нормально. Вот фрагмент кода, который вызывается для выполнения процессов Java (очищен для удобства чтения):
/bin/java myJavaProgram -DvariousFlags=true &> >(logger -p local3.info -t "my prefix") 2>&1 &
Вот где мой ум немного сбивает с толку - если я запускаю команду, которая вызывает эти сценарии с сервера, на котором Jenkins находится в качестве пользователя Jenkins, команда работает. Если я запустил его через графический интерфейс Jenkins, задание просто зависнет. Я запускаю в Jenkins следующую команду:
ssh -t jenkins@appserver.example.com 'appctl restart all' 2>/dev/null
Я подтвердил #!/bin/bash -x флаг того, что сценарий подходит к концу. Когда я бегу с ssh -vvv, следующая последняя строка вывода:
debug1: client_input_channel_req: канал 0 rtype ответ статуса выхода 0
Есть мысли о том, куда идти дальше? Есть ли лучший способ реализовать функцию системного журнала? Что-то не так с моим трубопроводом?
Logger, скорее всего, не работает в фоновом режиме, поэтому SSH считает, что у вас все еще открыт процесс, и не закрывает соединение.
Попробуйте добавить 2>/dev/null >/dev/null </dev/null внутри кавычек для вашей команды appctl, чтобы все дескрипторы файлов были закрыты на верхнем уровне.
Ответ Джейсона правильный на заданный мною вопрос. Однако я забыл упомянуть, что хотел сохранить appctl вывод в консоли Jenkins.
Джейсон побудил меня вернуться к перенаправлению. Я придумал следующее:
ssh -t jenkins@appserver.example.com 'appctl restart all 1>&2'
Похоже на перенаправление stdout к stderr делает SSH счастливым ...