Apa * tepatnya * yang kacau ketika saya membunuh -9 atau menarik daya?


13

Mempersiapkan

Saya sudah menjadi seorang programmer untuk beberapa waktu sekarang, tetapi saya masih agak bingung tentang hal-hal internal yang mendalam.

Sekarang. Saya sadar bahwa itu juga bukan ide yang baik:

  1. kill -9 a process (bad)
  2. secara spontan menarik steker listrik pada komputer atau server yang sedang berjalan (lebih buruk)

Namun, terkadang Anda harus melakukannya. Terkadang suatu proses tidak akan merespons apa pun yang Anda lakukan, dan kadang-kadang komputer tidak mau merespons, apa pun yang Anda lakukan.

Mari kita asumsikan sebuah sistem yang menjalankan Apache 2, MySQL 5, PHP 5, dan Python 2.6.5 melalui mod_wsgi.

Catatan: Saya paling tertarik dengan Mac OS X di sini, tetapi jawaban yang berkaitan dengan sistem UNIX akan membantu saya.

Perhatian ku

Setiap kali saya harus melakukan salah satu dari ini, terutama yang kedua, saya sangat khawatir untuk periode waktu bahwa ada sesuatu yang rusak. Beberapa file di suatu tempat bisa rusak - siapa yang tahu file mana? Ada lebih dari 1.000.000 file di komputer.

Saya sering menggunakan OS X, jadi saya akan menjalankan operasi "Verifikasi Disk" melalui Disk Utility. Akan melaporkan tidak ada masalah, tapi saya masih khawatir tentang ini.

Bagaimana jika beberapa file konfigurasi di suatu tempat kacau. Atau lebih buruk lagi, bagaimana jika file biner di suatu tempat rusak. Atau file skrip di suatu tempat rusak sekarang. Bagaimana jika beberapa perangkat keras rusak?

Bagaimana jika saya tidak mengetahuinya sampai bulan depan, dalam skenario kritis, ketika korupsi atau kerusakan menyebabkan malapetaka?

Atau, bagaimana jika data berharga sudah hilang?

Harapanku

Harapan saya adalah bahwa kekhawatiran dan kekhawatiran ini tidak berdasar. Lagi pula, setelah melakukan ini berkali-kali sebelumnya, belum ada hal buruk yang terjadi. Yang terburuk adalah saya harus memperbaiki beberapa tabel MySQL, tapi sepertinya saya tidak kehilangan data.

Tetapi, jika kekhawatiran saya tidak berdasar, dan kerusakan nyata dapat terjadi pada situasi 1 atau 2, maka harapan saya adalah bahwa ada cara untuk mendeteksi dan mencegahnya.

Pertanyaan saya)

Mungkinkah ini karena sistem operasi modern dirancang untuk memastikan bahwa tidak ada yang hilang dalam skenario ini? Mungkinkah ini karena perangkat lunak modern dirancang untuk memastikan tidak ada yang hilang? Bagaimana dengan desain perangkat keras modern? Tindakan apa yang dilakukan saat Anda mencabut steker listrik?

Pertanyaan saya adalah, untuk kedua skenario ini, apa yang sebenarnya salah, dan langkah apa yang harus diambil untuk memperbaikinya?

Saya mendapat kesan bahwa satu hal yang bisa salah adalah beberapa program mungkin tidak mem-flush data mereka ke disk, jadi setiap data yang sangat baru yang seharusnya ditulis ke disk (katakanlah, beberapa detik sebelum power pull) ) mungkin hilang. Tapi bagaimana dengan hal itu? Dan bisakah masalah hilangnya data 5 detik ini merusak sistem?

Bagaimana dengan korupsi file acak yang bersembunyi di suatu tempat di hutan besar file di hard drive saya?

Bagaimana dengan kerusakan perangkat keras?

Apa yang Paling Membantu Saya

  1. Penjelasan terperinci tentang apa yang terjadi secara internal ketika Anda membunuh -9 suatu proses atau menarik daya pada keseluruhan sistem. (Kelihatannya instan, tetapi bisakah seseorang memperlambatnya untuk saya?)

  2. Penjelasan dari semua hal yang bisa salah dalam skenario ini, bersama dengan probabilitas (kasar tentu saja) (yaitu, ini sangat tidak mungkin, tetapi ini kemungkinan) ...

  3. Deskripsi langkah-langkah yang ada di perangkat keras, sistem operasi, dan perangkat lunak modern, untuk mencegah kerusakan atau korupsi saat skenario ini terjadi. (untuk menghiburku)

  4. Petunjuk untuk apa yang harus dilakukan setelah kill -9 atau tarikan daya, di luar "memverifikasi disk", untuk memastikan tidak ada yang rusak atau rusak di suatu tempat di drive.

  5. Tindakan yang dapat diambil untuk memperkuat pengaturan komputer sehingga jika ada sesuatu yang harus dimatikan atau daya harus ditarik, potensi kerusakan dapat dikurangi.

  6. Beberapa informasi tentang file biner - bukankah benar bahwa file biner apache atau pustaka bisa memiliki byte acak atau dua rusak di tengah, yang tidak akan keluar dan menyebabkan masalah sampai nanti? Bagaimana saya bisa meyakinkan diri sendiri bahwa ini tidak terjadi sebagai akibat dari penarikan daya atau pembunuhan?

Terima kasih banyak!


Proses apa yang Anda kirim kill -9? Anda menyebutkan 'Apache 2, MySQL 5, PHP 5, dan Python 2.6.5 melalui mod_wsgi.' Apakah Anda membunuh beberapa dari ini. Mengetahui apa yang Anda bunuh akan memungkinkan respons yang lebih terarah atas implikasi melakukannya. Juga, apa yang sebenarnya terjadi membuat Anda ingin mematikan proses. Ketahuilah hal ini dan mungkin dapat mengidentifikasi akar penyebab masalah Anda alih-alih Anda hanya memahami implikasi metode brute force Anda untuk memperbaikinya. BTW, pada MacOS X, untuk mesin modern menahan tombol daya selama 10 detik daripada hanya menarik daya, kurang brutal.
Graham Dumpleton

Saya tidak tahu tentang kill -9 tetapi kecuali jika Anda memiliki semacam catu daya cadangan, saya pikir cukup aman untuk mengatakan bahwa SEMUA YANG terbunuh ketika Anda menarik steker listrik.
John Gardeniers

Jawaban:


9

Menarik kekuatan menyebabkan semuanya berhenti dalam penerbangan, tanpa peringatan. kill -9 memiliki efek yang sama pada satu proses, dengan paksa menghentikannya dengan SIGKILL .

Jika suatu proses terbunuh oleh kernel atau pemadaman listrik, itu tidak melakukan pembersihan. Itu berarti Anda bisa memiliki file setengah tertulis, status tidak konsisten, atau cache hilang. Anda biasanya tidak perlu khawatir tentang semua ini karena penjurnalan, status keluar dan cadangan baterai.

File sementara di / tmp akan secara otomatis hilang jika berada dalam tmpfs, tetapi Anda mungkin masih memiliki file kunci khusus aplikasi untuk dihapus, seperti kunci dan .p emok kunci untuk firefox.

Sebagian besar perangkat lunak cukup pintar untuk mencoba kembali transaksi jika tidak berhasil mencatat status keluar. Contoh yang bagus untuk ini adalah sistem surat biasa. Jika pesan dikirimkan, tetapi terputus di tengah, pengirim akan mencoba lagi nanti sampai berhasil.

Sistem file Anda mungkin dijurnal. Jika Anda memindahkan atau menulis file dan mati saat streaming, sistem file yang dijurnal masih akan merujuk yang asli. Filesystem yang dijurnal akan membuat perubahan non-destruktif, meninggalkan salinan lama, lalu hanya merujuk salinan baru sebagai langkah terakhir sebelum mengambil kembali ruang dari salinan lama yang ditempati pada disk.

Sekarang jika Anda memiliki array RAID, ia memiliki semua jenis buffer memori untuk meningkatkan kinerja dan memberikan keandalan dalam kegagalan daya. Kemungkinan besar filesystem Anda tidak akan tahu tentang cache di perangkat dan kondisinya, sehingga ia berpikir bahwa perubahan telah dilakukan ke disk, tetapi masih ada di cache RAID di suatu tempat. Jadi apa yang terjadi ketika listrik mati? Semoga Anda memiliki baterai fungsional di kandang RAID Anda dan Anda memantaunya. Kalau tidak, Anda memiliki sistem file yang rusak untuk fsck.

Ya, beberapa bit bisa menjadi rusak dalam biner, tapi saya tidak akan terlalu khawatir tentang itu pada perangkat keras modern. Jika Anda benar-benar paranoid, Anda dapat memantau kesehatan disk dan RAID Anda dengan alat yang sesuai, tetapi Anda tetap harus melakukannya. Lakukan pencadangan rutin dan dapatkan Catu Daya Tidak Ganggu.


5

Dalam shutdown yang tidak terduga, satu-satunya file yang harus rusak adalah file yang terbuka untuk ditulis. Pada sebagian besar sistem pada waktu tertentu, Anda mungkin tidak menulis ke file. Mungkin.

1 bunuh -9

POSIX SIGKILL dan tergantung pada implementasi. Proses yang menerima sinyal ini tidak akan diberi kesempatan untuk menanganinya.

1 Matikan

tergantung pada perangkat kerasnya. Kepala parkir otomatis di bawah momentum drive dan Semua yang ada di cache tulis Anda kehilangan penyegaran DRAM dan meluruh menjadi korupsi yang tidak dapat diperbaiki dalam beberapa detik. Hal yang sama terjadi pada memori sistem, cache CPU, register, dll.

Dari wdc.com (google: site: wdc.com Parking Head Pelindung)

Daya terputus: Hard drive direset. Head diparkir di zona pendaratan menggunakan energi spindle. Motor spindle berhenti.

2 - apa yang bisa salah

file yang dibiarkan terbuka tidak sepenuhnya ditulis. Jika file dibuka untuk ditulis, akan ada kerusakan data. File menulis dalam perangkat keras modern cepat dan PC modern biasanya tidak ditekankan dengan IO. Ini seperti berjalan dengan mata tertutup di jalan pedesaan yang sunyi. Sebagian besar waktu, Anda akan baik-baik saja.

3 - penanggulangan

lihat di atas untuk apa disk lakukan.

Cari sistem file yang dijurnal, sekarang normal: http://en.wikipedia.org/wiki/Journaling_file_system

Perangkat lunak seperti MS Word atau vi akan menulis ke file sementara daripada yang asli. Tujuannya adalah untuk tidak pernah meninggalkan sistem dalam keadaan di mana tidak ada salinan yang konsisten pada disk.

Windows menyimpan salinan registri (terlalu penting) Wikipedia: "Windows 2000 menyimpan salinan alternatif dari kumpulan registri (.ALT) dan berupaya untuk mengubahnya ketika korupsi terdeteksi" (Saya belum melakukan dukungan teknis sejak Win2k, jadi saya tidak yakin apa mekanisme baru MS)

4 - apa yang harus dilakukan

Dalam urutan kesulitan (mudah-sulit)

  • Simpan cadangan
  • Periksa apa yang terakhir Anda kerjakan
  • Boot dari disk yang terpisah dan cari tanggal / waktu modifikasi terakhir untuk mengetahui apa yang mungkin dilakukan sistem pada saat crash
  • Boot dari disk yang terpisah dan bandingkan md5sums semua file Anda dengan salinan offline.

Simpan cadangan adalah jawaban yang paling tepat, cadangan yang baik akan membuat Anda kembali ke versi yang dimodifikasi sebelumnya.

5

Kekuatan yang berlebihan? Pendidikan pengguna akhir? letakkan selotip dan kardus di atas tombol daya?

6

Kekurangan fungsi perangkat keras, driver disk yang rusak, kernel OS yang rusak, tidak adanya checksum atau crash saat upgrade, biner dan perpustakaan tidak dibuka baca-tulis sehingga mereka tidak rusak. Itu terjadi, tetapi jarang.


+1 untuk poin # 6
Bigbio2002

4

Adapun kill -9, ini mengirimkan sinyal ke proses untuk "mati" tepat di tempat. Proses mati (kecuali jika itu dalam tidur tanpa gangguan, dalam hal ini menjadi zombie). Tidak ada file yang ditutup, tidak ada data yang ditulis, dan program tidak dapat menangkap sinyal ini dan melakukan sesuatu yang lain. Tidak ada pembersihan, tidak ada apa-apa: itu hanya mati.

Sistem file saat ini sangat kuat; hal-hal seperti XFS, JFS, ext3, dan ext4 semuanya memiliki jurnal dan hal-hal lain untuk menjaga metadata filesystem tetap utuh.

Binari seperti Apache itu sendiri dan yang lainnya tidak akan rusak oleh kehilangan daya secara tiba-tiba atau oleh sistem kill, karena mereka berada dalam memori atau sedang dibaca; jika mereka sedang dibaca dari (misalnya, Apache HTTP mulai misalnya) ada kemungkinan lonjakan listrik dapat merusak biner, tetapi tampaknya tidak mungkin.

Saya memiliki Mac Mini, orang-orang sepertinya suka mematikan dingin (tidak peduli berapa kali saya memberi tahu mereka .....) dan itu terus berjalan.

Sebagian besar ,, selama Anda tidak mengandalkan kill -9 atau matikan secara teratur, saya tidak akan terlalu khawatir. Hal-hal yang jauh lebih buruk di masa lalu; Saya lebih khawatir tentang (misalnya) Solaris 2.6 daripada saya tentang Solaris 10 (dan seterusnya).



3

"Kill -9" tidak akan menyinkronkan operasi IO yang tertunda. Ini sering bukan masalah, tetapi jika sistem berada di bawah beban IO yang berat, Anda mungkin kehilangan data.

Ini lebih merupakan masalah dengan server, tempat pengontrol RAID (tanpa cache yang didukung baterai) dapat membuat cache menulis dan kehilangan data Anda.

Sunting : Satu hal lagi ... jika Anda bergantung pada drive yang dipasang di jaringan dan memiliki pegangan file yang terbuka, Anda kemungkinan besar meninggalkan file tersebut tidak konsisten atau rusak. Pada Windows, contoh klasik dari ini di mana Anda melihat ini adalah ketika pengguna me-mount file Outlook PST pada suatu bagian dan kehilangan daya atau konektivitas jaringan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.