Apa itu proses zombie?
Proses zombie adalah proses yang telah menyelesaikan tugasnya, tetapi proses induk (kemungkinan besar) telah mati atau macet secara tidak terduga. Mereka juga bisa menjadi indikasi kode kereta. Sebagian besar pengguna tidak memiliki pemahaman yang baik tentang apa itu proses zombie dan bagaimana pengaruhnya terhadap host Linux. Pertama dan terpenting, jumlah yang rendah (misalnya sepuluh, misalnya) proses zombie tidak berkontribusi pada beban sistem. Faktanya, ribuan zombie tidak akan berkontribusi pada beban sistem.
Menurut definisi, proses zombie tidak mengkonsumsi sumber daya, untuk sebagian besar. Setiap proses zombie masih dialokasikan nomor ID proses, atau PID. Pada sistem 32-bit, jumlah maksimum PID yang tersedia adalah 32.767. Untuk sistem 64-bit, jumlah tersebut meningkat secara eksponensial hingga lebih dari 4 juta.
Ada juga sejumlah kecil memori yang digunakan untuk setiap proses zombie. Secara teknis, dibutuhkan puluhan ribu, mungkin ratusan ribu proses zombie untuk menyebabkan kelelahan sumber daya sistem yang signifikan.
Ada 2 skenario yang akan saya bahas di sini. Yang pertama adalah proses memunculkan banyak PID anak, dan kemudian PID induk mogok atau mati tanpa menuai PID anak. Biasanya, masalah ini akan menunjukkan kemungkinan bug dengan program atau kode. Ketika ini terjadi, PID 1 (atau proses init) mengambil alih kepemilikannya. Untuk tujuan cara ini, cara tercepat untuk menyingkirkan zombie ini adalah dengan reboot. Dimungkinkan juga untuk membuat proses dummy dan meneruskan kepemilikan proses zombie tersebut kembali ke PID dummy untuk dibersihkan. Itu di luar jangkauan di sini. Nyalakan ulang dan selesaikan!
Skenario kedua adalah ketika suatu proses digantung ke titik di mana OS melihatnya berjalan, tetapi proses tersebut sebenarnya tidak melakukan apa-apa. Contoh yang saya gunakan untuk diskusi ini adalah daemon alat pelaporan bug otomatis (abrtd ) yang dikirimkan bersama Red Hat Enterprise Linux dan beberapa distribusi lainnya. Ini adalah alat yang hebat, dan saya suka memilikinya dan menjalankannya pada sistem karena memberi saya, sebagai sysadmin, pandangan yang lebih baik tentang apa yang oops'ing—atau crash—tetapi tidak menjalankan kernel crash.
Di lingkungan saya, daemon ini juga sedikit kelemahan. Secara default, abrtd hanya membuat informasi untuk aplikasi yang ditandatangani. Aplikasi apa pun dapat ditandatangani untuk menghasilkan bug, tetapi jika aplikasi yang tidak ditandatangani memicu abrtd , daemon melakukan gerakan membuat laporan bug dan kemudian menghapus semua yang dibuatnya. Perilaku ini dapat menyebabkan masalah dengan tindakan yang ditangguhkan untuk aplikasi yang tidak ditandatangani.
Mari kita lihat sebuah contoh. Seorang pengguna mengirimkan laporan insiden yang mengatakan bahwa sistem lambat karena enam proses zombie. Ada beberapa hadiah mati pada sistem yang abrtd sedang mengalami masalah. Saat Anda su - untuk melakukan root, Anda akan melihat yang berikut:
'abrt-cli status' timed out
Jika kita cek pada abrtd proses kita dapat melihat bahwa proses tersebut masih berjalan, tetapi ada proses turunan yang telah berjalan sejak 30/5.
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
Jadi abrtd secara teknis masih berjalan, tetapi proses pasca-pembuatan tersebut telah menciptakan status di mana beberapa laporan kerusakan ABRT baru mencoba dijalankan, tetapi berubah menjadi zombie. Pada titik ini, Anda dapat memulai ulang abrtd layanan, dan tindakan itu akan menghapus semua proses zombie.
Tapi, jika Anda tidak tahu itu masalahnya, inilah cara Anda melacak PID yang merupakan induk zombie menggunakan ps -xal memerintah. Perintah ini mengeluarkan lot info, jadi saya hanya akan menunjukkan kolom yang kita butuhkan:
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
Kolom keempat adalah PID induk, kolom kesepuluh adalah status proses anak (jelas Anda akan mencari PID dalam keadaan Z), dan kolom ketiga belas adalah proses anak. Menggunakan PID induk di kolom empat, Anda sekarang dapat mematikan proses induk itu, dan anak-anak zombienya juga akan hilang. Kecuali jika PID induknya adalah 1, dalam hal ini diperlukan boot ulang.
Saat beroperasi, kami tidak selalu memiliki kemewahan untuk me-reboot setiap saat. Secara pribadi, saya merasa me-reboot harus menjadi pilihan terakhir. Reboot menyembunyikan banyak dosa, dan membiarkan dosa-dosa itu muncul pada waktu yang paling tidak tepat, biasanya larut malam atau liburan akhir pekan!
Oh, dan beban pada sistem ini tidak berkurang sedikit pun setelah memulai ulang abrtd dan membersihkan 6 zombie itu.