Kapan dibutuhkan reboot?

Selain meningkatkan kernel, apakah ada perubahan pada sistem Linux yang memerlukan reboot? Saya tahu ada situasi di mana reboot membuat segalanya lebih mudah, tetapi adakah yang tidak bisa dilakukan kecuali dengan reboot?

Untuk memperjelas: Saya sedang memikirkan sistem desktop atau server tipikal yang tidak menderita kerusakan perangkat keras.

linux reboot

— Menandai
sumber

setiap hal dapat dilakukan tanpa me-reboot. bahkan mengubah kernel dapat dilakukan dengan menggunakan ksplice sehingga Anda dapat melakukan hot swap kernel Anda. Satu-satunya hal yang perlu Anda perhitungkan adalah fakta membuat segalanya tanpa me-reboot bisa menjadi sangat kompleks

— Kiwy

Pertanyaan Anda sangat luas, karena "sistem Linux" dapat berarti banyak hal yang sangat berbeda.

— Zrin

Juga "perubahan apa pun" dapat berarti banyak situasi yang berbeda. Apakah pemulihan dari hard drive gagal yang merupakan bagian dari MD mirror perubahan seperti itu? Jika ya, maka - sayangnya - kadang-kadang akan membutuhkan reboot, karena misalnya beberapa kegagalan HDD (pada beberapa pengontrol HDD) dapat membuat sistem tidak responsif. Tapi Anda mungkin tidak bertanya tentang "perubahan" seperti itu ...

— Zrin

@ Kiwy Secara teknis ksplice tidak mengubah kernel . Ksplice memungkinkan kernel yang berjalan untuk ditambal, saat sedang berjalan. Anda mungkin berpikir tentang kexec , yang memungkinkan citra kernel baru untuk dimuat "di atas" kernel yang sedang berjalan dalam memori.

— Thomas Nyman

Ini mengingatkan saya, windows XP (saya tidak pernah melampaui) tidak pernah menutup tentang restart bahkan jika itu hanya memperbarui IE8 (atau nomor apa pun) yang belum dibuka selama 4 tahun, sejak instalasi Windows dan karenanya perlu mengunduh browser.

— Shahbaz

Jawaban:

Beberapa hal muncul dalam pikiran:

Sembuh dari kepanikan kernel

Panic kernel, menurut definisi, tidak dapat dipulihkan dari tanpa me-restart kernel.
Pulihkan dari hang yang membuat Anda tanpa akses terminal

Jika sistem tidak responsif dan Anda terdampar tanpa cara untuk mengeluarkan perintah untuk memulihkan, satu-satunya hal yang mungkin dapat Anda lakukan adalah reboot. Biasanya, Anda ingin menghindari bersepeda dengan tenaga manual. Untuk situasi seperti ini, kernel Linux memiliki dukungan Magic SysRq yang dapat digunakan untuk me-reboot mesin dalam keadaan darurat.

Selama CONFIG_MAGIC_SYSRQopsi telah diaktifkan dalam konfigurasi kernel, dan kernel.sysrq sysctlopsi ini diaktifkan, Anda dapat mengeluarkan perintah langsung ke kernel dengan kombinasi tombol SysRq ajaib:

Perhatikan bahwa Alt+ di SysRqbawah ini berarti tekan dan tahan Alt , lalu tekan dan tahan SysRq (biasanya PrintScrntombol).
1. Alt+ SysRq+ r: mendapatkan kembali kendali atas keyboard
2. Alt+ SysRq+ e: kirim SIGTERMke semua proses, kecuali init, beri mereka kesempatan untuk mengakhiri dengan anggun
3. Alt+ SysRq+ i: kirim SIGKILLke semua proses, kecuali init, memaksa mereka untuk berakhir
4. Alt+ SysRq+ s: mencoba menyinkronkan semua sistem file yang terpasang
5. Alt+ SysRq+ u: remount semua sistem file hanya-baca
6. Alt+ SysRq+ b: reboot, atau
  
  Alt+ SysRq+ o: shutdown
Sebuah mnemonic untuk kombinasi tombol SysRq ajaib untuk mencoba reboot yang anggun adalah:

" R eboot E ven I f S ystem U tterly B roke "

Untuk server tanpa kepala, bahkan ada target iptables yang memungkinkan urutan SysRq jarak jauh melalui jaringan.
Pulihkan dari keadaan tidak bisa di-boot

Jika sistem telah dibawa ke keadaan di mana boot biasa tidak dimungkinkan (misalnya sebagai akibat dari peningkatan sistem yang gagal, sistem file yang rusak, dll.), Maka satu-satunya cara untuk mengakses konsol pemulihan pada sistem mungkin dengan reboot menggunakan opsi waktu boot yang sesuai.
Ubah parameter kernel waktu boot

Beberapa parameter kernel (mis. auditUntuk mengaktifkan / menonaktifkan audit kernel) hanya dapat diatur ketika kernel dimuat saat boot.

— Thomas Nyman
sumber

"Reboot Sekalipun Sistem Benar-Benar Rusak" Aku mendukung pertanyaan ini untuk berjaga-jaga, tapi kurasa aku tidak akan pernah melupakannya.

— embedded.kyle

Mungkin perlu dicatat Anda bisa keluar dari kepanikan menggunakan kexec dan menghindari reboot penuh. Ini juga berlaku sama untuk keluar dari titik status unbootable. (mereka bukan hal yang sama dengan cara apa pun, setidaknya pada sistem x86). Namun +1 untuk sisa jawaban ini.

— Vality

@Vality Terima kasih atas komentar Anda. Jika kexec memerlukan reboot, mungkin tergantung sampai batas tertentu pada sudut pandang seseorang. The dokumentasi kdump misalnya menggambarkan kexec-on-panik sebagai reboot yang mempertahankan citra memori sistem kernel. Adapun poin tentang keadaan unbootable, saya juga mempertimbangkan hal-hal seperti kesalahan konfigurasi bootloader (misalnya kegagalan untuk memuat kernel di tempat pertama), di mana kexec tidak membantu. Mengingat sifat pertanyaan, saya pikir beberapa perbedaan pendapat tentang semantik tidak dapat dihindari.

— Thomas Nyman

@ThomasNyman Terima kasih atas tanggapan terperinci Anda, melihat pertanyaan yang saya rasa benar. Saya pikir berbicara tentang kexec mungkin hanya akan memperumit hal-hal yang tidak perlu bagi audiens target atau pertanyaan ini. Dan Anda juga membuat poin bagus tentang kesalahan boot-loader.

— Vality

Saya tidak pernah memperhatikan bahwa SysRq kecil ditulis di bawah layar cetak! Ini luar biasa. Saya berharap saya tahu ini ketika saya belajar pemrograman modul kernel!

— Shahbaz

Ada dua kali saya bisa memikirkan di mana saya ingin reboot:

Ketika saya perlu memastikan bahwa sistem dapat boot dalam keadaan yang tepat.

Saya pernah bekerja pada sistem yang memiliki beberapa daemon yang dikonfigurasi saat sedang berjalan. Setelah berjalan selama beberapa tahun, kegagalan daya menyebabkannya untuk reboot, tetapi daemon itu bukan bagian dari proses startup dan tidak ada yang tahu bagaimana itu telah dikonfigurasi tahun sebelumnya. Sistem mati selama berhari-hari sementara kami menemukan cara mengkonfigurasi ulang.

Sebenarnya reboot adalah satu-satunya cara untuk mengetahui dengan pasti bahwa sistem Anda akan memulai kembali dengan benar setelah listrik padam.
Ketika pustaka sistem telah diperbarui.

Katakanlah bahwa celah keamanan utama telah ditemukan di perpustakaan yang dibagikan dengan banyak aplikasi / server pada sistem. Anda dapat memperbarui pustaka tanpa me-reboot, tetapi berapa banyak proses yang masih berjalan dengan pustaka tidak aman yang dimuat? Anda bisa dengan susah payah memulai kembali apa saja menggunakan perpustakaan lama (jika Anda bisa mengetahuinya), tapi itu rawan kesalahan dan bisa memakan waktu lebih lama dari sekadar me-reboot.

Mem-boot ulang adalah cara terbaik untuk memastikan bahwa semua proses yang berjalan masih tidak menggunakan pustaka lama yang bermasalah.

— Gabe
sumber

Ada cara yang lebih baik untuk menemukan semua binari tergantung pada pustaka tertentu jika Anda menggunakan manajer paket yang baik. revdep-dibangun kembali dari Gentoo muncul di pikiran.

— Spidey

@Spidey: Setelah Anda membangun kembali binari-binari itu, bagaimana Anda memastikan bahwa tidak ada proses lama yang berjalan dengan pustaka buggy?

— Gabe

Bagaimana Anda tahu daemon mana yang memuat pustaka yang melanggar?

— Gabe

@ Gabe Misalnya Anda dapat memeriksa proses mana perpustakaan telah dipetakan ke ruang memori mereka menggunakan lsofsebelum Anda memutakhirkan perpustakaan.

— Thomas Nyman

@ Gabe Tentu, dan sementara saya setuju bahwa itu adalah alasan yang sangat baik untuk reboot, OP secara eksplisit tidak menanyakan dalam kasus mana reboot lebih mudah digunakan, tetapi ketika reboot benar-benar diperlukan .

— Thomas Nyman

Jika maksud Anda adalah perubahan yang direncanakan dalam konfigurasi perangkat lunak dan menganggap perangkat keras berfungsi dengan baik (saya belum melihat itu) dan perangkat lunak bebas bug (Anda tahu ...), maka hanya bug di kernel atau driver yang akan memaksa Anda untuk reboot :)

Selain itu ... Saya tidak yakin apakah mungkin untuk mengganti inittanpa beralih ke mode pengguna tunggal dan melakukan beberapa sihir yang pada dasarnya tidak jauh berbeda dari reboot.

— Zrin
sumber