Di UNIX, ketika proses orangtua menghilang, saya berpikir bahwa semua proses anak mereset init sebagai orangtua mereka. Apakah ini tidak benar sepanjang waktu? Apakah ada pengecualian?
Di UNIX, ketika proses orangtua menghilang, saya berpikir bahwa semua proses anak mereset init sebagai orangtua mereka. Apakah ini tidak benar sepanjang waktu? Apakah ada pengecualian?
Jawaban:
Memindahkan komentar saya ke sebuah jawaban .... Saya tidak percaya ada pengecualian.
Menemukan ini "kadang-kadang proses induk dibunuh sebelum anaknya terbunuh. Dalam kasus ini, proses" induk dari semua proses, " init
menjadi PPID (induk proses ID) baru. Kadang-kadang proses ini disebut proses yatim." sumber
Demikian pula dijelaskan dalam blog IBM : "Orang tua meninggal atau terbunuh sebelum anak. Dalam skenario di atas, proses anak menjadi proses anak yatim (seperti yang telah kehilangan orang tuanya). Di Linux, init
proses datang untuk menyelamatkan yatim piatu memproses dan mengadopsinya. Ini berarti setelah seorang anak kehilangan orang tuanya, init
proses itu menjadi proses orang tuanya yang baru. "
Tiga jawaban ditulis pada tahun 2014, semuanya mengatakan bahwa di Unices dan di Linux prosesnya diperbaiki untuk memproses # 1 tanpa terkecuali. Tiga jawaban yang salah. ☺
Seperti yang dikatakan SUS , dikutip dalam salah satu jawaban lain di sini jadi saya tidak akan mengutipnya lagi, proses induk anak-anak yatim diatur untuk proses yang ditentukan implementasi . Cristian Ciupitu berhak untuk membaca dokumentasi Linux untuk melihat apa yang didefinisikan oleh implementasinya. Tetapi dia disesatkan oleh dokumentasi itu, yang tidak konsisten dan tidak mutakhir.
Dua tahun sebelum ketiga jawaban ini ditulis, dan cepat muncul hingga tiga tahun yang lalu pada saat pertama kali menulis jawaban ini, kernel Linux berubah. Pengembang systemd menambahkan kemampuan proses untuk mengatur diri mereka sebagai "subreaper". Dari Linux 3.4 dan selanjutnya proses dapat mengeluarkan prctl()
system call dengan PR_SET_CHILD_SUBREAPER
opsi, dan sebagai hasilnya, bukan proses # 1, akan menjadi induk dari semua proses turunan yatim piatu mereka. The halaman manual untukprctl()
up-to-date, tetapi halaman manual lainnya belum dibawa up to date dan membuat konsisten.
Dalam versi 10.2, FreeBSD memperoleh kemampuan yang sama, memperluas procctl()
panggilan sistem PROC_REAP_ACQUIRE
dan PROC_REAP_RELEASE
opsi yang ada. Itu mengadopsi mekanisme ini dari DragonFly BSD; yang diperoleh di versi 4.2, awalnya bernama reapctl()
tetapi diganti selama pengembangan menjadi procctl()
.
Jadi ada pengecualian, dan yang cukup menonjol: Di Linux, FreeBSD / PC-BSD, dan DragonFly BSD, proses induk dari anak-anak yatim diatur ke proses leluhur terdekat dari anak yang ditandai sebagai subreaper, atau proses # 1 jika tidak ada proses subreaper leluhur. Berbagai utilitas pengawasan daemon - termasuk systemd (yang pengembangnya menempatkan ini di kernel Linux di tempat pertama), pemula, dan nosh service-manager
- sudah memanfaatkan ini.
Jika seperti daemon pengawas tidak memproses # 1, dan itu memunculkan layanan seperti sesi login interaktif, dan dalam satu sesi tidak (cukup salah arah) trik mencoba untuk "daemonize" oleh ganda fork()
ing , maka proses seseorang akan berakhir sebagai anak dari pengawas daemon, bukan dari proses # 1. Berharap untuk dapat langsung menghasilkan daemon dari dalam sesi login adalah kesalahan mendasar, tentu saja. Tapi itu jawaban lain.
procctl()
. Halaman Manual DragonFly BSD. § 2.Menurut exit
halaman manual dari Spesifikasi Single UNIX®, Versi 2:
ID proses induk dari semua proses anak dan proses zombie yang ada pada proses pemanggilan diatur ke ID proses dari proses sistem yang bergantung pada implementasi. Artinya, proses ini diwarisi oleh proses sistem khusus.
Untuk sebagian besar varian Unix, proses khusus itu adalah init
(PID 1).
wait(2)
Halaman manual Linux mengkonfirmasi ini:
Jika proses induk berakhir, maka anak-anak "zombie" -nya (jika ada) diadopsi oleh init (8), yang secara otomatis melakukan penantian untuk menghapus zombie.
Halaman manual FreeBSD wait(2)
, NetBSD wait(2)
, OpenBSD wait(2)
dan Mac OS X wait(2)
mengkonfirmasi hal ini juga:
Jika proses induk berakhir tanpa menunggu semua proses anaknya berakhir, proses child yang tersisa akan diberikan ID proses induk 1 (ID proses init).
wait(3C)
Halaman manual Oracle Solaris 11.1 mengonfirmasi ini juga:
Jika proses induk berakhir tanpa menunggu proses anaknya berakhir, ID proses induk dari setiap proses anak diatur ke 1, dengan proses inisialisasi mewarisi proses anak; lihat
Intro(2)
.
Saya tidak percaya begitu. Itu selalu pergi ke proses init.