Fabric: Сбой перезагрузки на хостах Ubuntu 16.04

То же самое и с запуском (перезагрузка)

То же самое с руководством run неудивительно - очевидно, что что-то изменилось в отношении обработки Ubuntu перезагрузки, соединений SSH и т. Д.

Ничего очевидного не приходит на ум, но reboot() (Fab, а не Linux) довольно прост - он просто вызывает sudo('reboot') и временно настраивает общие настройки переподключения Fabric, чтобы он мог обрабатывать переподключение после нетривиальной последовательности перезагрузки. (по сравнению с настройкой по умолчанию, которая быстро сдалась бы).

См. Https://github.com/fabric/fabric/blob/c0224a52df59821f21a8c0bd47ce15e42c2046a4/fabric/operations.py#L1244 - вы можете попробовать это настроить.

Также попробуйте включить ведение журнала Paramiko (см. Нижнюю часть нашей страницы устранения неполадок - http://www.fabfile.org/troubleshooting.html), поскольку это может дать подсказку.

На самом деле, если задуматься, похоже, что Ubuntu reboot почему-то никогда не завершает работу или не отправляет код выхода обработчикам выполнения Fabric ( run / sudo ), поскольку вы заметили, что sudo - вот что злится, когда вы месите Enter после ожидания.

Если вы посмотрите на код reboot() , он ожидает, что вызов sudo('reboot') в конечном итоге завершится, так что он может A) немного подождать и B) инициировать повторное соединение.

Тот факт, что на стороне Fabric выполнение просто зависает в sudo означает, что что-то удаленно нарушает это ожидание. Как-то странно. _Может_ быть ошибкой в ​​самой Fabric, но больше похоже на плохое поведение на удаленном конце. (PS: на каких версиях ткани вы это видите?)

Навскидку подумал - мы могли бы поставить timeout= на sudo , а затем вокруг него except TimeoutException: pass . Это гарантирует, что даже в этой (странной) ситуации мы по умолчанию попытаемся восстановить соединение.

Единственным недостатком может быть случай, когда reboot на самом деле зависает, а система не перезагружается, но мы не сделаем что-то _худшее_ для этого случая указанным выше изменением - бесконечное зависание просто произойдет на цикл подключения, а не внутри sudo .

Другое действительно странное измененное поведение в Ubuntu 16.04 заключается в следующем. Когда я запускаю poweroff в сеансе ssh, машина отключается, но сеансы SSH зависают! Нет возможности использовать Ctrl + C, Ctrl + D или что-то еще. Все, что я могу сделать, это подождать _lot_, затем ssh прервется:
packet_write_wait: Connection to 192.168.56.11: Broken pipe

Я действительно не очень разбираюсь в обработке SSH-соединений, но это может быть точно такая же проблема, как и при перезагрузке.

Я только что столкнулся с прерванной перезагрузкой (свежий Ubuntu 16.04 на AWS, Fabric == 1.12.0), но по-другому. Для меня это просто подбрасывает:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "reboot"

Запуск sudo reboot в терминале вручную работает (перезагрузка хоста).

Стоит отметить:

$ readlink /sbin/reboot 
/bin/systemctl
$ readlink /sbin/shutdown
/bin/systemctl

И еще одна странность. Я изменил код перезагрузки, чтобы использовать aws-cli, и после его вызова (который занимает ~ 1 секунду, кажется, что он асинхронный) я запускаю sudo('add-apt-repository --yes ppa:nginx/stable') . Всегда работало, но теперь после перезагрузки тоже вернуло -1:

sudo: add-apt-repository --yes ppa:nginx/stable

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: add-apt-repository --yes ppa:nginx/stable
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "add-apt-repository --yes ppa:nginx/stable"

Затем я попытался сделать ткань для повторного подключения, добавив fabric.network.disconnect_all() . В результате был запрошен пароль (почему ??):

[...] sudo: add-apt-repository --yes ppa:nginx/stable
[...] Login password for 'ubuntu': 

И он начал работать только после того, как я добавил, например, time.sleep(60 * 3) после перезагрузки. Это, очевидно, плохой пластырь, и теперь я озадачен, как правильно решить проблему с паролем. Похоже, это связано с этой проблемой.

Проблема, кажется, в том, что «перезагрузка» теперь иногда «слишком быстрая», прежде чем статус команды вернется через соединение ssh.

(Совет: если в результате у вас заморожено ssh-соединение: введите \n~. aka enter, tilde, period. Это escape-символ ssh по умолчанию, затем команду отключения для ssh. Если вы просто попробуете ctrl- c или ctrl-d, ssh пытается передать это процессу, запущенному на другой стороне.)

Одно из решений - использовать shutdown -r +1 , который запланирует перезагрузку на следующую минуту, а затем подождет минуту для ее запуска, а затем начнет попытки повторного подключения. По общему признанию, подождать минуту - не самое лучшее.

Хакерская вещь, которую стоит попробовать: shutdown -r +0 должен быть эквивалентен reboot , но в моих ограниченных тестах Ubuntu-16.04, запущенных в VirtualBox, он, как правило, дает на долю секунды больше, показывая следующий приглашение оболочки непосредственно перед отключением сеанса ssh вручную.

это вероятно дублирование # 1444

Если демон инициализации переключен на выскочку, перезагрузка работает должным образом. Похоже, что systemd немедленно убивает sshd.

В пакете systemd Debian / Ubuntu была ошибка, которая при завершении работы убивала сетевую службу до SSH, поэтому все зависало.
Это было исправлено в последней версии. Не знаю о статусе пакета Ubuntu.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

Сообщил об ошибке для Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002

У меня также были проблемы с использованием reboot () в некоторых моих скриптах. Я обнаружил, что при подключении с паролем перезагрузка работала правильно, но при использовании аутентификации по ключевому файлу соединение зависало (перезагрузка была выполнена).

Ошибка ubuntu https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002 отмечена как исправленная в 16.10, но еще не в 16.04, и неясно, когда это произойдет.

Текущее поведение для меня заключается в том, что paramiko / fabric мгновенно определяет, что соединение ssh было закрыто, но это происходит до того, как paramiko / fabric увидит, что команда перезагрузки завершена. По крайней мере, он не висит на неопределенный срок, как в исходном отчете.

Fatal error: sudo() received nonzero return code -1 while executing!
...
Aborting.

Обычный reboot() делал это для меня в нескольких тестах на AWS EC2 и локальной виртуальной машине virtualbox. (Я всегда использовал аутентификацию по ключевым файлам.)

Я нашел короткий и элегантный обходной путь, как я предлагал без таких подробностей выше:

reboot(command="shutdown -r +0")

У меня это сработало, как и ожидалось (в нескольких моих тестах на AWS EC2 и локальных виртуальных машинах виртуальных машин, на которых была установлена ​​последняя версия Ubuntu 16.04). Обратите внимание, что команда «shutdown -r now» вела себя как «перезагрузка» и, похоже, не работала.

Я быстро просмотрел справочные страницы freebsd и openbsd, и, похоже, у них есть команда выключения, которая поддерживает эти параметры. Я подозреваю, что команда «shutdown -r +0» будет работать практически для любой системы unix, на которой работает «перезагрузка». Таким образом, можно рассмотреть возможность изменения команды по умолчанию или обновления документации. (Но мне было бы интересно сначала увидеть отчет об испытании системы BSD.)

shutdown -r +0 нам недостаточно. Поскольку перезагрузка не принимает тайм-аут вручную, я даже пробовал что-то вроде:

try:
    sudo("shutdown -r +0", timeout=300)
except NetworkError:
    pass
# in case the sudo times out during reboot
sleep(15)

Несмотря на все это махание рукой, следующая команда зависает на неопределенный срок. Возможно ли, что пул соединений удерживает (и использует) мертвое соединение? Если да, есть ли обходной путь? Могу ли я временно уменьшить тайм-аут на уровне подключения?

Действительно, вам нужно заменить существующее соединение, как это делает reboot() :

https://github.com/fabric/fabric/blob/1.13.2/fabric/operations.py#L1289 -L1294

Приносим извинения, чтобы восстановить старую проблему, я также могу подтвердить, что эта проблема возникает при попытке перезагрузить контейнер LXC. Предложение @ploxiln об использовании command="shutdown -r +0" сработало для нас.

Подтверждение этой ошибки при новой установке FreeBSD 11.1 с установленным bash:

reboot(wait=1) приводит к:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /usr/local/bin/bash -l -c "reboot"

Aborting.
Traceback (most recent call last):
…
    raise env.abort_exception(msg)
hosts.FabricException: sudo() received nonzero return code -1 while executing!

В конце концов, мне это понадобилось, чтобы начать работу после повторения комментариев @ ambsw-technology и

sudo('shutdown -r +0')
time.sleep(30)
fabric.state.connections.connect(env.host_string)

К вашему сведению, я все еще вижу это на серверах 18.04.2 LTS.

Что-нибудь исправить? также возникает проблема с 16.04