Mengapa memperbarui sistem Linux yang sedang berjalan tidak bermasalah?


25

Sudah bertahun-tahun saya menggunakan sistem Linux setiap hari, dan saya tidak pernah memiliki masalah besar dengan memperbarui sistem ketika sedang berjalan, tetapi saya masih bertanya-tanya mengapa ini memungkinkan.

Biarkan saya membuat contoh.

Misalkan program "A" dari paket tertentu sedang berjalan pada suatu sistem. Program ini, pada titik tertentu, perlu membuka file lain ("B") dari paket yang sama. Setelah itu, program "A" menutup "B" karena tidak membutuhkannya lagi. Misalkan sekarang saya memperbarui paket "A" dan "B" milik. "A" tidak secara langsung dipengaruhi oleh operasi ini, setidaknya untuk saat ini, karena sedang berjalan dalam RAM dan pembaruan hanya diganti "A" pada hard disk. Misalkan "B" telah diganti pada sistem file juga. Sekarang "A" perlu membaca "B" lagi untuk beberapa alasan. Pertanyaannya adalah: apakah mungkin "A" dapat menemukan versi "B" yang tidak kompatibel dan kerusakan atau kegagalan fungsi dengan cara lain?

Mengapa tidak ada yang memperbarui sistem mereka dengan me-reboot dengan live CD atau prosedur serupa lainnya?


Saya cenderung lebih suka menghindari pembaruan seperti itu, bukan karena mekanisme memperbarui (ini bisa dilakukan dengan baik), tetapi lebih karena preferensi untuk menguji aplikasi dan konfigurasi saya terhadap perubahan, pertama. Maka saya akan memiliki sistem terpisah yang sekarang diperbarui untuk hanya beralih ke. Tapi selain itu, memperbarui di userland umumnya tidak menjadi masalah, dan untuk perbaikan kecil atau keamanan, saya hanya akan melakukannya.
Skaperen

Jawaban:


23

Memperbarui Userland Jarang Masalah

Anda sering dapat memperbarui paket pada sistem langsung karena:

  1. Pustaka bersama disimpan dalam memori, bukan dibaca dari disk pada setiap panggilan, sehingga versi lama akan tetap digunakan hingga aplikasi dimulai ulang.
  2. File yang terbuka sebenarnya dibaca dari file-deskriptor , bukan nama file, sehingga konten file tetap tersedia untuk aplikasi yang sedang berjalan bahkan ketika dipindahkan / diganti namanya / dihapus sampai sektor-sektor itu ditulis berlebihan atau deskriptor file ditutup.
  3. Paket yang membutuhkan pemuatan ulang atau memulai kembali biasanya ditangani dengan benar oleh manajer paket jika paket telah dirancang dengan baik. Misalnya, Debian akan memulai kembali layanan tertentu setiap kali libc6 ditingkatkan.

Secara umum, kecuali jika Anda memperbarui kernel Anda dan tidak menggunakan ksplice, maka program atau layanan mungkin perlu direstart untuk mengambil keuntungan dari pembaruan. Namun, jarang ada kebutuhan untuk reboot sistem untuk memperbarui apa pun di userland, meskipun pada desktop terkadang lebih mudah daripada memulai kembali layanan individual.

Lihat juga

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode


Tetapi apa yang akan terjadi, jika Anda membutuhkan semua cache-memory? Dalam hal ini, pustaka berbagi harus dimuat lagi dari disk ...
Nils

3
Sebenarnya deskripsi # 1 tidak begitu jelas. Isi file perpustakaan lama tetap di bawah inode (asli) yang terpisah, bahkan jika semua nama yang menghubungkannya hilang, selama beberapa proses file dibuka, atau kontennya dipetakan, datanya tetap berbeda (dan sistem file tidak dapat akan dipasang ulang r / o sampai pembatalan tautan file selesai). Proses yang memetakan file asli masih memiliki pemetaan memori ke konten asli.
Skaperen

@Nils Saya bukan ahli, tetapi jika Anda kehabisan cache, bukankah itu akan ditulis untuk bertukar dan membaca kembali dari sana? Jika itu penuh maka beberapa proses mungkin akan diblokir sebelum bisa mengambil memori dari proses lain yang sudah menggunakannya.
Joe

@ Jo no - swap juga ram. Skaperen menjelaskan apa yang terjadi: file-handle ditahan dengan utuh. Jadi pada dasarnya program ini memiliki satu hasle ke pustaka lama (sudah tidak ada), yang tidak akan dihapus sampai pegangan itu bebas lagi - ini semua pada level sistem file - bukan pada level RAM.
Nils

4

Ya, apa yang Anda gambarkan adalah mungkin, tetapi sebagian besar waktu jika file tersebut disertakan dengan paket, itu akan menjadi pustaka atau file lain yang dibaca sekali dan hanya sekali (karena tidak berubah, tidak ada alasan untuk baca beberapa kali). Juga jika file tersebut diperlukan dalam jangka panjang, aplikasi tersebut kemungkinan akan membiarkan handle file tetap terbuka, di mana bahkan jika itu diganti pada sistem file yang sebenarnya, handle file yang terbuka akan membuat versi lama tetap terbuka.

Dalam kebanyakan kasus, data apa pun yang dibaca beberapa kali selama masa proses adalah data pengguna / variabel, dan ini tidak akan berubah selama peningkatan paket. Plus karena datanya variabel, programmer mana pun yang waras akan memastikan programnya dapat mengubahnya dari satu baca ke yang berikutnya.


File masih dapat dibaca kembali sebagai "backing store" jika pemetaannya tidak membuat perubahan dalam memori (yang jika tidak akan menggeser backing store untuk bertukar jika tersedia), dan salinan dalam memori akan dibuang karena tekanan permintaan lain untuk menggunakan ingatan. Tetapi ini bukan masalah karena file asli masih terbuka atau dipetakan. Pustaka pengganti adalah file baru dan berbeda yang belum dibuka proses lama.
Skaperen

1
@ Skaperen Saya berasumsi Anda sedang berbicara tentang file yang dipetakan memori. Ini bukan masalah saat memutakhirkan paket. Semua manajer paket membuat file baru untuk menggantikan yang lama alih-alih menimpa mereka. Sebenarnya ini adalah satu-satunya cara untuk melakukannya karena eksekusi yang dapat dijalankan tidak dapat dimodifikasi, hanya dapat dibatalkan tautannya.
Patrick

4

Misalkan "B" telah diganti pada sistem file juga. Sekarang "A" perlu membaca "B" lagi untuk beberapa alasan. Pertanyaannya adalah: apakah mungkin "A" dapat menemukan versi "B" yang tidak kompatibel dan kerusakan atau kegagalan fungsi dengan cara lain?

Ini mungkin, tetapi dalam banyak kasus tidak mungkin. Jika "B" adalah pustaka kode, maka versi aslinya biasanya tidak akan ditutup. "A" akan terus menggunakan versi asli "B". Jika Anda menjalankan "A" setelah pembaruan, versi "B" yang baru akan digunakan. Selama pembaruan, ada risiko bahwa versi yang tidak kompatibel dapat dimuat. Namun, karena cara pustaka kode dimuat ini seharusnya hanya menjadi masalah jika "A" memerlukan fungsionalitas yang tidak ada dalam versi "B" yang dimuatnya.

Praktik pengkodean yang baik menjaga antarmuka agar fungsinya tetap sama. Akibatnya, tidak masalah versi mana yang dimuat, selain jika ada bug yang diperbaiki pada versi yang lebih baru.

File konfigurasi adalah masalah yang sedikit berbeda, tetapi biasanya dibaca saat startup. Dalam hal ini, "A" tidak akan membaca "B" kecuali memuat ulang konfigurasi diubah. Sekali lagi, akan menjadi praktik pengkodean yang buruk untuk mengubah format atau arti file konfigurasi. Versi file konfigurasi yang tidak kompatibel harus memiliki nama yang berbeda, sehingga tidak akan menimbulkan masalah.

Mengapa tidak ada yang memperbarui sistem mereka dengan me-reboot dengan live CD atau prosedur serupa lainnya?

Mematikan dan me-reboot dari versi yang berbeda akan menyebabkan pemadaman layanan. Untuk server, ini umumnya tidak diinginkan. Bagaimanapun, manajer paket pada sistem yang berjalan menyadari perangkat lunak dan versi yang telah diinstal. Live CD memiliki daftar sendiri perangkat lunak yang diinstal, mungkin dengan versi yang berbeda. Ini membuatnya sulit untuk secara andal memutakhirkan sistem yang sedang berjalan dari live CD.

Live CD kadang-kadang digunakan ketika rilis baru O / S sedang diinstal. Dalam hal ini, instalasi O / S yang bersih biasanya dilakukan. Ini dapat membatasi jumlah file yang tidak digunakan dari versi sebelumnya yang dipertahankan. Ini bisa lebih dari upaya meningkatkan sistem live. Namun, jika partisi root yang berbeda digunakan, itu dapat membatasi risiko macet dengan sistem yang diperbarui sebagian yang tidak dapat di-boot.


0

Ada beberapa kasus di mana ini adalah masalah:

  • JDK memutakhirkan saat java-VM sedang berjalan: Saya bertanya pada myselv pertanyaan yang sama dengan yang Anda dapatkan - Saya memiliki kucing jantan berjalan yang menggunakan java. Sekarang setelah pembaruan patch dari JDK masih berjalan tanpa masalah - jadi sepertinya.

Sekarang penjelasannya adalah cache-memory. OK - saya memulai memory-hog-program untuk menggunakan semua RAM yang tersedia - dan kemudian kucing jantan jatuh (setelah saya mengakses aplikasi yang berjalan di sana).

  • Kernel-Upgrade pada sistem SuSE: Pada SuSE kernel lama dan modul-modulnya terhapus segera setelah patch-upgrade kernel. Jika Anda ingin menggunakan sesuatu yang baru, yang membutuhkan modul-kernel, yang belum dimuat hingga sekarang, layanan akan gagal.

2
Kedengarannya seperti beberapa bagian Tomcat dihidupkan kembali, atau perpustakaan dinamis digunakan di bawah tingkat Java (misalnya dlopen () dan semacamnya) yang dapat berakhir dengan campuran API langsung.
Skaperen

@ Skaperen bahkan ketika menggunakan perpustakaan bersama - jika mereka ditutup setelah menggunakan program apa pun harus memiliki masalah jika cache semakin jarang ...
Nils

1
Deskriptor file terbuka memiliki kekuatan yang sama untuk menyimpan data pada disk sebagai nama file dalam direktori. Inode asli tidak akan dihapus selama ada hard-link pada disk atau deskriptor file terbuka. Cache tidak ada hubungannya dengan itu. Sekarang, beberapa program menutup deskriptor file mereka ketika mereka tidak menggunakannya dan itu dapat membuat data hilang.
dmckee

@ dmckee Benar. Kami semakin dekat ke inti. Jadi apa yang normal untuk program "normal": buka perpustakaan dan tetap buka, atau muat perpustakaan dan tutup sesudahnya?
Nils
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.