BerandaComputers and TechnologySystemd mengejar kejadian bind

Systemd mengejar kejadian bind

Selamat datang di LWN.net

Konten khusus langganan berikut telah tersedia untuk Anda oleh pelanggan LWN. Ribuan pelanggan bergantung pada LWN untuk berita terbaik dari Linux dan komunitas perangkat lunak gratis. Jika Anda menikmati ini artikel, harap pertimbangkan untuk menerima tawaran uji coba di sebelah kanan. Terima kasih telah mengunjungi LWN.net!

Langganan uji coba gratis

Coba LWN gratis selama 1 bulan: tanpa pembayaran atau kartu kredit diperlukan. Mengaktifkan langganan uji coba Anda sekarang dan lihat mengapa ribuan pembaca berlangganan LWN.net.

Oleh Jonathan Corbet
13 November 2020

Proyek kernel memiliki fokus yang kuat untuk tidak merusak ruang pengguna aplikasi; jika sesuatu bekerja dengan rilis kernel tertentu, itu seharusnya terus bekerja dengan rilis berikutnya. Jadi mungkin mengecilkan hati baca eksposisi panjang pada pembobolan API ruang pengguna yang tampak di pengumuman untuk systemd 247-rc2 melepaskan. Perubahan pada file konfigurasi udev akan diperlukan untuk menjaga sistem bekerja, tetapi proyek systemd mengklaim bahwa itu “ bukan [the] kesalahan systemd atau udev, tapi disebabkan oleh perubahan kernel yang tidak kompatibel yang terjadi di Linux 4.12 “. Sepertinya saat yang tepat untuk melihat apa yang terjadi, bagaimana administrator perlu merespons, dan apakah ada yang dapat dilakukan hindari hal semacam ini terjadi lagi.

Komputer modern cenderung sangat dinamis, dengan perangkat (dari keduanya variasi fisik dan virtual) muncul dan menghilang saat sistem sedang berlari. Kernel menangani detail tingkat rendah berkenaan dengan ini acara perangkat, tetapi terserah ruang pengguna untuk mengurus sisanya. Untuk yang terjadi, ruang pengguna perlu tahu ketika sesuatu telah berubah konfigurasi sistem.

Untuk itu, peristiwa dipancarkan ke ruang pengguna dari dalam inti driver kernel subsistem setiap kali ada perubahan; untuk Misalnya, mencolokkan perangkat USB akan menghasilkan satu atau selengkapnya TAMBAHKAN untuk memberi tahu ruang pengguna bahwa perangkat baru tersebut tersedia. The udev daemon bertugas menanggapi ini acara sesuai dengan seperangkat aturan; itu dapat membuat node perangkat, set izin, beri tahu komponen ruang pengguna lainnya, dan banyak lagi, semuanya sebagai tanggapan ke properti yang dilampirkan ke acara dengan mencocokkan aturan. Sekumpulan dari peristiwa yang mungkin terjadi relatif kecil dan tidak sering berubah.

Melanggar systemd

Namun, pada Juli 2017, Dmitry Torokhov menambahkan dua acara baru jenis disebut BIND dan MEMPERLONGGAR. Mereka memang dimaksudkan untuk memungkinkan ruang pengguna untuk menangani perangkat yang membutuhkan bantuan sebelum dapat menjadi berfungsi penuh – mereka yang membutuhkan beban firmware, misalnya. Untuk driver yang mendukung mekanisme baru, a BIND acara untuk perangkat akan mengikuti TAMBAHKAN setelah perangkat siap beroperasi. Perubahan ini adalah bagian dari rilis kernel 4.14 pada November 2017 (bukan 4.12 sebagaimana tercantum dalam pengumuman systemd).

Kemudian di bulan yang sama, laporan bug mendarat di pelacak bug KDE; ini mungkin kasus pertama di mana seseorang melihat masalah terkait dengan acara baru. Hanya laporan itu yang berhasil daftar kernel pada akhir 2018, meskipun – lebih dari satu tahun kemudian. Oleh kemudian, 4.14 telah dibuat menjadi kernel dukungan jangka panjang dan dikirimkan oleh distributor, dengan relatif sedikit keluhan dari pengguna. Benar, Greg Kroah-Hartman bingung tentang mengapa masalah muncul setahun kemudian. Itu ternyata a ubah ke systemd yang menyebabkannya menyebarkan acara baru.

Secara khusus, masalah tersebut tampaknya berasal dari cara udev itu (yang merupakan bagian dari proyek systemd) melampirkan tag ke acara. Tag ini, yang ditetapkan dan digunakan oleh aturan udev, mengontrol cara pengguna ruang akan menyiapkan perangkat baru. Ada asumsi yang dibangun bahwa hanya akan ada satu acara untuk mengumumkan keberadaan perangkat baru, jadi melampirkan tag ke sana acara sudah cukup. Saat acara kedua BIND acara) acara up, status perangkat disetel ulang dan tag tersebut dilupakan, mengarah ke perangkat terkait tidak disiapkan dengan benar.

Sebagai “perbaikan” jangka pendek, systemd telah ditambal ke abaikan saja acara baru. Itu menyebabkan hal-hal bekerja seperti yang mereka lakukan sebelumnya, dengan biaya menyembunyikan peristiwa itu seluruhnya. Itu tidak pernah a solusi jangka panjang; acara baru ditambahkan karena suatu alasan dan beberapa perangkat membutuhkannya untuk pengaturan yang tepat. Jadi harus ada solusi yang lebih baik ditemukan untuk jangka panjang; solusi itu memiliki dua aspek, salah satunya mungkin mengganggu pengguna yang telah membuat aturan udev mereka sendiri.

Memperbaiki systemd

Bagian pertama adalah pengerjaan ulang dari mekanisme “tag” yang disediakan oleh udev. Tag adalah properti khusus yang dapat dilampirkan, lalu dicocokkan aturan selanjutnya atau dikonsumsi oleh ruang pengguna. Daripada melampirkan tag ke acara, seperti yang telah dilakukan hingga sekarang, udev menempelkannya ke perangkat, jadi tag ditambahkan sebagai tanggapan terhadap TAMBAHKAN acara akan tetap ada untuk MENGIKAT juga. Untuk kasus di mana aturan hanya perlu merespons tag ditambahkan ke acara saat ini, CURRENT_TAGS baru daftar properti hanya tag itu; dengan demikian memegang nilai bahwa TAGS Properti diadakan di rilis sebelumnya.

Namun, bagian lain adalah perubahan yang harus diterapkan pada sejumlah kumpulan aturan udev. Pertimbangkan, misalnya, cuplikan ini diambil dari secara acak file aturan yang dipilih ( 10-dm-disk.rules secara khusus) di a Sistem Fedora 32:

     # Peristiwa "add" diproses hanya dengan coldplug!     ACTION!="Tambahkan | ubah", GOTO="dm_end" 

Tindakan menyebabkan seluruh file akan dilewati untuk apa pun selain TAMBAH atau PERUBAHAN acara; khususnya apa yang akan terjadi dengan BIND acara. Itu akan menimbulkan properti terkait dengan peristiwa tersebut akan hilang – dan perangkat masuk pertanyaan yang akan disiapkan secara tidak benar (jika ada). Cara mengatasinya adalah dengan mengubahnya baris untuk dibaca:

     ACTION=="hapus", GOTO="dm_end" 

Itu menyebabkan aturan dilewati (dan negara yang terkait dilupakan) hanya jika perangkat dihapus dari sistem.

Masalahnya di sini adalah bahwa aturan-aturan ini ditulis dengan asumsi itu tidak ada jenis acara baru yang akan ditambahkan, jadi apa pun yang tidak dikenali sebagai menambahkan atau memodifikasi perangkat dapat diabaikan. Ternyata ada a sejumlah kode tertentu yang berjalan sebagai respons terhadap peristiwa perangkat yang memiliki masalah serupa. Hal ini menunjukkan, pada dasarnya, semacam protokol efek osifikasi yang membuat lebih sulit untuk menambahkan jenis acara API yang disediakan oleh kernel. Memang, pada 2018, Torokhov berkomentar :

Nah, tampaknya kita tidak bisa lagi memperluas antarmuka uevent jenis acara baru, setidaknya sampai kita pergi dan memperbaiki semua turunan udev dan berikan waktu untuk menyelesaikannya.

Pada saat itu, ada diskusi tentang kemungkinan mengembalikan perubahan, menyebabkan acara baru menghilang. Tapi pendekatan itu berpotensi untuk dibuat regresi sendiri, karena beberapa sistem mungkin bergantung pada hasil acara-acara itu; rilis kernel yang menambahkannya berusia satu tahun pada saat itu, Lagipula. Ada juga diskusi tentang menambahkan semacam kenop untuk mengaktifkan atau nonaktifkan pembuatan BIND dan TIDAK DIIKAT acara, tapi yang tidak pernah terjadi. Sebaliknya, Torokhov dijelaskan bekerja dalam proyek systemd untuk membuat perubahan yang dijelaskan di atas, dan Kroah-Hartman menjawab : “ Jadi semua harus baik-baik saja “.

Regresi?

Dengan keberuntungan, semua akan bagus, tetapi harus dibayar mahal dari beberapa bekerja dalam komunitas systemd selama dua tahun terakhir; sistemd pengembang telah menyatakan ketidaksenangan mereka:

Kami mohon maaf atas kerusakan ini dan persyaratan untuk memperbarui paket menggunakan antarmuka ini. Kami ingin sekali lagi menggarisbawahi hal itu ini bukan disebabkan oleh perubahan systemd / udev, tetapi akibat dari kernel perubahan perilaku.

Apakah ini melanggar aturan “tidak ada regresi” pada kernel? Jawabannya hampir pasti harus “ya”; kode yang bekerja dengan 4.13 tidak lagi berfungsi dengan 4.14. Apa yang seharusnya dilakukan tentang itu agak kurang jelas. Seandainya masalah dilaporkan ke komunitas kernel lebih cepat, mungkin saja dimungkinkan untuk mengembalikan dan mendesain ulang perubahan; setelah itu diterapkan Namun, selama setahun, itu bukanlah pilihan yang sederhana. Orang bisa membantah bahwa komunitas kernel seharusnya menemukan cara lain untuk memperbaiki regresi; pengumuman systemd 247-rc2 mencoba membuat kasus itu. Tapi begitu Torokhov mengeposkan bahwa masalah telah diatasi di sisi systemd, memang ada tidak ada lagi tekanan untuk melakukan itu.

Mungkin pelajaran nyata di sini adalah bahwa masyarakat akan dilayani dengan lebih baik dengan hubungan yang lebih erat antara proyek kernel dan pengelolaan proyek utilitas tingkat rendah seperti systemd. Hubungan itu agak kadang-kadang tegang, dan tidak banyak tempat di mana koperasi, diskusi lintas proyek dapat dilakukan. Kehadiran systemd pengembang di acara seperti Linux Plumbers Conference terbatas, dan para pengembang tersebut – bukan tanpa alasan – tidak menemukan kernel mailing daftar untuk menjadi tempat yang sepenuhnya ramah. Kami semua mengerjakan hal yang sama sistem, meskipun, dan kita mungkin akan memiliki waktu yang lebih mudah jika kita bisa berbicara sedikit lebih banyak.



Apakah Anda menyukai artikel ini? Terima kami penawaran langganan uji coba menjadi dapat melihat lebih banyak konten seperti itu dan berpartisipasi dalam diskusi.


( Masuk untuk mengirim komentar)

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments