Jenkins Relaunch Slave Agent через странность SSH

Question

Иногда один из моих подчиненных агентов Дженкинса помечается Дженкинсом как офлайн. Агент на самом деле работает просто отлично, но сервер Jenkins не может показаться ssh ему. Перезапуск ведомого агента не дает ничего, кроме пустой консоли журнала.

Действительно странным и странным решением этой проблемы является следующее:

1. настроить подчиненный агент на использование неверного IP-адреса
2. перезапустить подчиненный агент (на этом этапе может быть несколько строк журнала, указывающих на попытку ssh)
3. снова сконфигурируйте подчиненный агент и на этот раз используйте правильный IP-адрес
4. перезапустить рабский агент

Кажется, это решает проблему каждый раз. Кто-нибудь испытал это и знает о лучшем решении?

Answer 1

Я столкнулся с чем-то похожим на Jenkins 2.222.3. После сбоя большинство узлов восстановилось и было повторно подключено к мастеру, но некоторые из них этого не сделали. Я перезагрузил вышедшие из строя подчиненные машины, что совершенно не помогло. Я сравнил конфигурацию исправных и отказавших ведомых устройств, проверил подключение / брандмауэр и т. Д. Единственным признаком различия было то, что, согласно главному журналу, после сбоя "хорошие" ведомые устройства пытались повторно подключиться несколько раз, так как некоторые из них Присутствовали следующие сообщения журнала:

Попытка повторно подключить slavexxx

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

Похоже, пара подчиненных застряла при первой попытке и остались в каком-то бесконечном цикле.

Возможно, перезапуск Jenkins исправил бы это, но, к счастью, я нашел более легкий обходной путь: я изменил настройку удаленного корневого каталога с /foo/bar/ на /foo/bar или наоборот. Да, я изменил только завершающий /, поэтому новый и старый путь остаются семантически одинаковыми. Тем не менее Дженкинс, вероятно, почувствовал, что изменение удаленного корневого каталога было достаточно хорошей причиной, чтобы прервать текущий процесс повторного подключения и начать новый.

YMMV