Fabric: Ubuntu 16.04 호스트에서 재부팅이 중단됨

run ( 'reboot')와 똑같습니다.

수동 run 와 동일하다는 것은 놀라운 일이 아닙니다. Ubuntu의 재부팅 처리, SSH 연결 등과 관련하여 분명히 변경된 사항이 있습니다.

눈에 띄는 것은 없지만 reboot() (리눅스가 아닌 Fab)은 매우 기본적입니다. 단순히 sudo('reboot') 를 호출하고 Fabric의 일반 재 연결 설정을 일시적으로 조정하여 사소하지 않은 재부팅 시퀀스 후 재 연결을 처리 할 수 ​​있습니다. (기본값과 비교하여 매우 빠르게 포기합니다).

https://github.com/fabric/fabric/blob/c0224a52df59821f21a8c0bd47ce15e42c2046a4/fabric/operations.py#L1244 참조 -이를 조정 해 볼 수 있습니다.

또한 단서를 얻을 수 있으므로 Paramiko의 로깅을 활성화 해보십시오 (문제 해결 페이지 하단 참조-http://www.fabfile.org/troubleshooting.html).

사실, 우분투의 reboot 은 (는) Fabric의 실행 핸들러 ( run / sudo )에 종료 코드를 제출하거나 종료하지 않는 것처럼 들립니다 run sudo 는 기다렸다가 Enter를 으깨면 화를냅니다.

reboot() 코드를 보면 sudo('reboot') 호출이 결국 종료 될 것으로 예상하므로 A) 잠시 기다린 후 B) 재 연결을 시작할 수 있습니다.

Fabric 측에서 실행이 sudo 된다는 사실은 원격으로 무언가가 그 기대를 위반하고 있음을 의미합니다. 좀 이상해. _ 아마 _ Fabric 자체의 버그 일 수 있지만 원격지에서는 나쁜 동작처럼 느껴집니다. (추신 : 어떤 패브릭 버전이 표시 되나요?)

엉뚱한 생각- timeout= 에 sudo 를 설정 한 다음 그 주위에 except TimeoutException: pass 설정할 수 있습니다. 이렇게하면이 (이상한) 상황에서도 기본적으로 재 연결을 시도합니다.

단점은 reboot 가 실제로 중단 되고 시스템이 실제로 재부팅되지 않는 경우입니다. 그러나 위의 변경으로 인해 해당 경우에 대해 _ 더 나쁜 _ 상황을 만들 수는 없습니다. 무한 중단이 계속 발생합니다. sudo 대신 연결 루프.

Ubuntu 16.04에서 정말 이상하고 변경된 동작은 다음과 같습니다. ssh 세션에서 poweroff 를 실행하면 시스템의 전원이 꺼지지 만 SSH 세션이 중단됩니다! Ctrl + C, Ctrl + D 등의 방법은 없습니다. 내가 할 수있는 일은 _lot_을 기다린 다음 ssh가 다음과 같이 중단되는 것입니다.
packet_write_wait: Connection to 192.168.56.11: Broken pipe

나는 SSH 연결 처리의 깊은 주머니에 실제로 관심이 없지만 이것은 재부팅과 똑같은 문제 일 수 있습니다.

방금 재부팅이 중단되었지만 (AWS의 최신 Ubuntu 16.04, 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, 마침표를 입력합니다. 이것이 기본 ssh 이스케이프 문자이고 ssh에 대한 disconnect 명령입니다. ctrl- c 또는 ctrl-d, ssh는 다른 쪽에서 실행중인 프로세스에이를 전달하려고합니다.)

한 가지 해결책은 shutdown -r +1 를 사용하는 것입니다. 그러면 다음 1 분 동안 재부팅을 예약 한 다음 시작될 때까지 잠시 기다린 다음 다시 연결을 시도합니다. 물론 1 분을 기다리는 것은 좋지 않습니다.

시도해 볼 수있는 해키 한 것 : shutdown -r +0 는 reboot 와 동일해야하지만 VirtualBox에서 실행되는 Ubuntu-16.04의 제한된 테스트에서는 몇 분의 1 초가 더 오래 걸리고 다음을 보여줍니다. 수동 ssh 세션 연결을 끊기 직전에 쉘 프롬프트.

이것은 아마도 # 1444의 복제 일 것입니다.

init 데몬이 upstart로 전환되면 재부팅이 예상대로 작동합니다. systemd가 sshd를 즉시 죽이는 것 같습니다.

Debian / Ubuntu의 systemd 패키지에 버그가 있었는데, 시스템 종료시 SSH 서비스 이전에 네트워크 서비스를 종료하여 모든 것이 중단되었습니다.
최신 포인트 릴리스에서 수정되었습니다. Ubuntu 패키지 상태에 대해 모릅니다.

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

Ubuntu에 대한 버그를보고했습니다.
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002

또한 일부 스크립트에서 reboot () 사용과 관련된 문제가있었습니다. 암호로 연결하면 재부팅이 올바르게 작동하지만 키 파일 인증을 사용하면 연결이 끊어지는 것을 알았습니다 (재부팅이 완료되었습니다).

우분투 버그 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.

Plain reboot() 은 (는) AWS EC2 및 로컬 가상 상자 VM에 대한 몇 가지 테스트에서 저를 위해 일관되게 수행했습니다. (항상 키 파일 인증을 사용했습니다.)

위의 세부 사항없이 제안한대로 짧고 우아한 해결 방법을 찾았습니다.

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

예상대로 작동했습니다 (AWS EC2 및 로컬 가상 박스 VM에 대한 몇 가지 테스트에서 모두 최신 우분투 16.04를 실행합니다). "shutdown -r now"는 "reboot"처럼 작동하고 작동하지 않는 것 같습니다.

freebsd 및 openbsd man 페이지를 간략히 살펴 보았는데 해당 매개 변수를 지원하는 종료 명령이있는 것으로 보입니다. "shutdown -r +0"명령이 "reboot"가 작동하는 거의 모든 유닉스 시스템에서 작동 할 것이라고 생각합니다. 따라서 기본 명령을 변경하거나 문서를 업데이트 할 때 고려할 수 있습니다. (그러나 먼저 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" 사용 제안이 우리에게 효과적이었습니다.

bash가 설치된 FreeBSD 11.1을 새로 설치할 때이 오류를 확인합니다.

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 및 @ploxiln 주석을 수정 한 후 작업을 수행하기 위해 이것이 필요했습니다. 나는 우분투 16.04 LTS 서버 (Windows 클라이언트에서)에 대해 실행 중입니다.

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

참고로, 18.04.2 LTS 서버에서 여전히 이것을 볼 수 있습니다.

이것에 대한 수정 사항이 있습니까? 16.04에서도 문제가 발생합니다.