Fabric: Reboot rusak pada host Ubuntu 16.04

Dibuat pada 18 Jul 2016 · 21Komentar · Sumber: fabric/fabric

Fungsi bawaan reboot() , yang telah bekerja dengan sempurna baik pada host Ubuntu 14.04 dan FreeBSD 10.x, tetapi rusak pada host Ubuntu 16.04.

Apa yang terjadi di Ubuntu 14.04:
Saya menerima keluaran seperti ini dan sistem di-boot ulang, setelah Fabric di-boot ulang terhubung kembali.

[ubuntu] out:
[ubuntu] out:
[ubuntu] out: Broadcast message from root<strong i="9">@ubuntu</strong>
[ubuntu] out:
[ubuntu] out:   (/dev/pts/0) at 15:02 ...
[ubuntu] out:
[ubuntu] out:
[ubuntu] out:
[ubuntu] out:
[ubuntu] out: The system is going down for reboot NOW!
[ubuntu] out:
[ubuntu] out:

Apa yang terjadi di Ubuntu 16.04:

Tidak ada keluaran sama sekali dari perintah tersebut.
Sistem benar-benar mulai me-reboot (masih tidak ada output di Fabric)
Sistem menyelesaikan boot ulang, tetapi Fabric tidak menyadarinya, tidak terhubung kembali, masih tidak ada keluaran.
Kain hanya duduk di sana menunggu selamanya.

Jika saya menekan tombol enter dalam keadaan ini, Fabric sebenarnya melanjutkan, tetapi menampilkan pesan ini sebelumnya:

No handlers could be found for logger "paramiko.transport"
Warning: sudo() received nonzero return code -1 while executing 'reboot'!

Saya menggunakan kode ini untuk reboot:

def reboot_():
    with settings(warn_only=True):
        print 'rebooting'
        start_time = time.time()
        reboot(wait=1200)
        print 'reboot took: {} seconds'.format(time.time() - start_time)

Bug Core Needs investigation

Sumber

hyperknot

👍4

Komentar yang paling membantu

Bug ubuntu https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002 ditandai sebagai diperbaiki pada 16.10, tetapi belum pada 16.04, dan tidak jelas kapan akan diperbaiki.

Perilaku saat ini bagi saya adalah paramiko / fabric langsung mendeteksi bahwa koneksi ssh ditutup, tetapi sebelum paramiko / fabric melihat perintah reboot telah selesai. Setidaknya itu tidak menggantung tanpa batas seperti dalam laporan asli.

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

Biasa reboot() melakukan itu secara konsisten untuk saya dalam beberapa pengujian terhadap AWS EC2 dan VM virtualbox lokal. (Saya selalu menggunakan keyfile auth.)

Saya telah menemukan solusi singkat dan elegan, seperti yang saya sarankan tanpa banyak detail di atas:

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

Itu berfungsi seperti yang diharapkan bagi saya (dalam beberapa pengujian saya terhadap AWS EC2 dan VM virtualbox lokal, semuanya menjalankan ubuntu 16.04 terbaru). Perhatikan bahwa "shutdown -r now" berperilaku seperti "reboot" dan sepertinya tidak berfungsi.

Saya melihat sekilas halaman manual freebsd dan openbsd, dan tampaknya mereka memiliki perintah shutdown yang mendukung parameter tersebut. Saya menduga bahwa perintah "shutdown -r +0" akan bekerja untuk hampir semua sistem unix yang bekerja "reboot". Jadi bisa dipertimbangkan untuk mengubah perintah default, atau memperbarui dokumentasi. (Tapi saya tertarik untuk melihat laporan pengujian pada sistem BSD terlebih dahulu.)

ploxiln pada 4 Feb 2017

👍4

Semua 21 komentar

Ini persis sama dengan run ('reboot')

hyperknot pada 18 Jul 2016

Itu sama dengan manual run tidak mengherankan - jelas ada sesuatu yang berubah terkait penanganan reboot Ubuntu, koneksi SSH, dll.

Tidak ada yang jelas terlintas dalam pikiran, tetapi reboot() (Fab, bukan Linux) cukup mendasar - ini hanya memanggil sudo('reboot') , dan untuk sementara mengubah pengaturan koneksi ulang umum Fabric sehingga dapat menangani penyambungan kembali setelah urutan reboot nontrivial (versus default, yang akan menyerah cukup cepat).

Lihat https://github.com/fabric/fabric/blob/c0224a52df59821f21a8c0bd47ce15e42c2046a4/fabric/operations.py#L1244 - Anda mungkin ingin mencoba mengubahnya.

Juga coba aktifkan pencatatan Paramiko (lihat bagian bawah halaman pemecahan masalah kami - http://www.fabfile.org/troubleshooting.html) karena ini mungkin menghasilkan petunjuk.

bitprophet pada 20 Jul 2016

Sebenarnya, setelah dipikir-pikir, sepertinya Ubuntu reboot entah bagaimana tidak pernah keluar atau mengirimkan kode keluar ke penangan eksekusi Fabric ( run / sudo ), karena Anda mencatat bahwa sudo adalah yang marah saat Anda mash Enter setelah menunggu.

Jika Anda melihat kode reboot() , panggilan sudo('reboot') akan keluar pada akhirnya, sehingga dapat A) menunggu sebentar dan B) memulai penyambungan kembali.

Fakta bahwa, di pihak Fabric, eksekusi hanya tergantung di dalam sudo berarti ada sesuatu yang melanggar ekspektasi itu dari jarak jauh. Agak aneh. _Mungkin_ bug di Fabric itu sendiri, tetapi lebih terasa seperti perilaku buruk di ujung jarak jauh. (PS: versi fabric mana yang Anda lihat ini?)

Berpikir begitu saja - kita mungkin bisa menetapkan timeout= pada sudo , kemudian except TimeoutException: pass di sekitarnya. Ini akan memastikan bahwa bahkan dalam situasi (aneh) ini, kami secara default mencoba menyambung kembali.

Satu-satunya downside adalah kasus di mana reboot benar-benar macet dan sistem tidak benar-benar me-reboot, tetapi tidak seperti kami membuat sesuatu _lebih buruk_ untuk kasus itu dengan perubahan di atas - hang tak terbatas hanya akan terjadi pada loop koneksi bukannya dalam sudo .

bitprophet pada 20 Jul 2016

Perilaku lain yang sangat aneh dan berubah di Ubuntu 16.04 adalah sebagai berikut. Ketika saya menjalankan poweroff dalam sesi ssh, mesin mati, tetapi sesi SSH hang! Tidak ada cara untuk Ctrl + C, atau Ctrl + D, atau apa pun. Yang bisa saya lakukan hanyalah menunggu _lot_ lalu ssh dibatalkan dengan:
packet_write_wait: Connection to 192.168.56.11: Broken pipe

Saya benar-benar tidak terlalu memahami penanganan koneksi SSH, tetapi ini mungkin masalah yang persis sama dengan reboot.

hyperknot pada 20 Jul 2016

Saya baru saja mengalami booting ulang yang rusak (Ubuntu 16.04 terbaru yang baru di AWS, Fabric == 1.12.0) tetapi dengan cara yang berbeda. Bagi saya itu hanya melempar:

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

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

Menjalankan sudo reboot di terminal dengan tangan bekerja (host reboot).

fillest pada 6 Sep 2016

👍2

Mungkin perlu diperhatikan:

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

fillest pada 6 Sep 2016

Dan hal aneh lainnya. Saya telah mengubah kode reboot untuk menggunakan aws-cli dan setelah panggilannya (yang membutuhkan ~ 1sec, sepertinya itu asynchronous) saya menjalankan sudo('add-apt-repository --yes ppa:nginx/stable') . Itu selalu berhasil, tetapi sekarang setelah reboot kembali -1 juga:

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"

Kemudian saya mencoba membuat kain untuk disambung kembali dengan menambahkan fabric.network.disconnect_all() . Itu mengakibatkan meminta kata sandi (mengapa ??):

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

Dan itu mulai bekerja hanya setelah saya menambahkan mis time.sleep(60 * 3) setelah reboot. Yang jelas merupakan pembalut luka yang buruk, dan sekarang saya bingung bagaimana menangani masalah kata sandi dengan benar. Sepertinya ini terkait dengan masalah ini.

fillest pada 6 Sep 2016

Masalahnya tampaknya "reboot" sekarang terkadang "terlalu cepat", sebelum status perintah kembali melalui koneksi ssh.

(Tip: Jika Anda berada pada koneksi ssh yang macet sebagai akibatnya: ketik \n~. aka enter, tilde, titik. Itu adalah karakter default ssh escape, lalu putuskan perintah untuk ssh. Jika Anda hanya mencoba ctrl- c atau ctrl-d, ssh mencoba meneruskannya ke proses yang berjalan di sisi lain.)

Salah satu solusinya adalah menggunakan shutdown -r +1 , yang akan menjadwalkan booting ulang untuk menit berikutnya, lalu tunggu sebentar untuk memulai, lalu mulai mencoba menyambungkan kembali. Memang, menunggu sebentar tidaklah bagus.

Hal hacky untuk dicoba: shutdown -r +0 harus setara dengan reboot , tetapi dalam pengujian terbatas saya pada Ubuntu-16.04 yang berjalan di VirtualBox, ini cenderung memberikan sepersekian detik lebih lama, menunjukkan yang berikutnya shell prompt sebelum memutuskan sesi ssh manual.

ploxiln pada 4 Okt 2016

👍2

ini mungkin dup dari # 1444

ploxiln pada 4 Okt 2016

Jika daemon init dialihkan ke upstart, booting ulang berfungsi seperti yang diharapkan. Sepertinya systemd segera mematikan sshd.

palbee pada 1 Nov 2016

Ada bug pada paket Debian / Ubuntu dari systemd yang, saat dimatikan, mematikan layanan jaringan sebelum SSH jadi semuanya hang.
Itu diperbaiki pada rilis poin terbaru. Tidak tahu tentang status paket Ubuntu.

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

alexkiousis pada 11 Nov 2016

Melaporkan bug untuk Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002

hyperknot pada 26 Nov 2016

Saya juga mengalami masalah terkait penggunaan reboot () di beberapa skrip saya. Saya menemukan bahwa ketika menghubungkan dengan kata sandi, reboot berfungsi dengan benar, tetapi ketika menggunakan otentikasi-keyfile, koneksi terputus (reboot selesai).

stefan-wegener pada 5 Des 2016

Bug ubuntu https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002 ditandai sebagai diperbaiki pada 16.10, tetapi belum pada 16.04, dan tidak jelas kapan akan diperbaiki.

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

Biasa reboot() melakukan itu secara konsisten untuk saya dalam beberapa pengujian terhadap AWS EC2 dan VM virtualbox lokal. (Saya selalu menggunakan keyfile auth.)

Saya telah menemukan solusi singkat dan elegan, seperti yang saya sarankan tanpa banyak detail di atas:

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

ploxiln pada 4 Feb 2017

👍4

shutdown -r +0 tidak cukup bagi kami. Karena reboot tidak menerima batas waktu manual, saya bahkan telah mencoba sesuatu seperti:

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

Meskipun semua tangan ini melambai, perintah selanjutnya berhenti tanpa batas. Apakah mungkin bahwa kumpulan koneksi menahan (dan menggunakan) koneksi yang mati? Jika ya, apakah ada solusinya? Dapatkah saya mengurangi waktu tunggu tingkat koneksi untuk sementara?

ambsw-technology pada 5 Jul 2017

Memang, Anda perlu mengganti koneksi yang ada, seperti yang dilakukan reboot() :

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

ploxiln pada 5 Jul 2017

👍1

Maaf untuk menghidupkan kembali masalah lama, saya juga dapat mengonfirmasi bahwa masalah ini terjadi saat mencoba mem-boot ulang wadah LXC. Saran @ploxiln untuk menggunakan command="shutdown -r +0" berhasil untuk kami.

ecnepsnai pada 11 Des 2017

👍1

Mengonfirmasi kesalahan ini pada penginstalan baru FreeBSD 11.1 dengan bash diinstal:

reboot(wait=1) hasil dalam:

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!

tehfink pada 7 Feb 2018

Saya akhirnya membutuhkan ini untuk menyelesaikan semuanya setelah membaca komentar @ ambsw-technology dan

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

aggieNick02 pada 7 Feb 2019

FYI, saya masih melihat ini terhadap server 18.04.2 LTS.

aggieNick02 pada 17 Jun 2019

👍1

Ada perbaikan untuk ini? juga mendapatkan masalah dengan 16.04

cgd1 pada 23 Apr 2020

Apakah halaman ini membantu?

0 / 5 - 0 peringkat

Masalah terkait

Fabric 2 - Jalankan tugas di Grup (dengan argumen)

haydenflinner · 5Komentar

py2.7.5 kesalahan hebat: ImportError: tidak dapat mengimpor nama NetworkError

neemxyang · 6Komentar

Peta jalan / pembaruan kemajuan untuk Fabric 2?

SamuelMarks · 3Komentar

UnicodeEncodeError saat memanggil fungsi put dengan unicode u '\ xff' dan stream.encoding adalah None

zhaoguixu · 5Komentar

Hapus referensi SCP di dokumen Fabric

omzev · 6Komentar