it-swarm-id.com

Bagaimana jika 'kill -9' tidak berfungsi?

Saya punya proses yang tidak bisa saya bunuh dengan kill -9 <pid>. Apa masalahnya dalam kasus seperti itu, terutama karena saya adalah pemilik dari proses itu. Saya pikir tidak ada yang bisa menghindari opsi kill.

491
tshepang

kill -9 ( SIGKILL ) selalu berfungsi, asalkan Anda memiliki izin untuk menghentikan prosesnya. Pada dasarnya proses tersebut harus dimulai oleh Anda dan bukan setuid atau setgid, atau Anda harus root. Ada satu pengecualian: bahkan root tidak dapat mengirim sinyal fatal ke PID 1 (proses init).

Namun kill -9 tidak dijamin bekerja segera. Semua sinyal, termasuk SIGKILL, dikirimkan secara serempak: kernel mungkin membutuhkan waktu untuk mengirimkannya. Biasanya, mengirimkan sinyal membutuhkan paling banyak beberapa mikrodetik, hanya waktu yang dibutuhkan target untuk mendapatkan waktu. Namun, jika target telah memblokir sinyal , sinyal akan mengantri sampai target membuka blokir itu.

Biasanya, proses tidak dapat memblokir SIGKILL. Tetapi kode kernel dapat, dan memproses mengeksekusi kode kernel ketika mereka memanggil panggilan sistem . Kode kernel memblokir semua sinyal ketika menginterupsi panggilan sistem akan menghasilkan struktur data yang terbentuk buruk di suatu tempat di kernel, atau lebih umum lagi pada beberapa invarian kernel yang dilanggar. Jadi jika (karena bug atau kesalahan desain) suatu sistem panggilan blok tanpa batas, mungkin secara efektif tidak ada cara untuk mematikan proses. (Tetapi proses akan terbunuh jika pernah menyelesaikan panggilan sistem.)

Proses yang diblokir dalam panggilan sistem berada di sleep tidak terputus . Perintah ps atau top akan (pada sebagian besar unit) menampilkannya dalam status D (asal untuk “ d isk ”, saya pikir).

Kasus klasik dari lama tidak terputusnya tidur adalah proses mengakses file lebih dari NFS ketika server tidak merespons; implementasi modern cenderung tidak memaksakan tidur tanpa gangguan (mis. di Linux, opsi mount intr memungkinkan sinyal untuk mengganggu akses file NFS).

Terkadang Anda mungkin melihat entri bertanda Z (atau H di Linux, saya tidak tahu apa perbedaannya) dalam keluaran ps atau top. Ini secara teknis bukan proses, itu adalah proses zombie, yang tidak lebih dari entri dalam tabel proses, disimpan di sekitar sehingga proses induk dapat diberitahu tentang kematian anaknya. Mereka akan pergi ketika proses induk memperhatikan (atau mati).

Kadang-kadang ada proses dan tidak dapat dibunuh karena:

  • menjadi zombie. Yaitu. proses yang orang tua tidak membaca status keluar. Proses tersebut tidak menggunakan sumber daya apa pun kecuali entri PID. Dalam top itu ditandai Z
  • salah tidur tanpa gangguan. Seharusnya tidak terjadi tetapi dengan kombinasi kode kernel kereta dan/atau perangkat keras kereta itu kadang-kadang terjadi. Satu-satunya metode adalah reboot atau menunggu. Dalam top itu ditandai oleh D.
101
Maciej Piechotka

Sepertinya Anda mungkin memiliki proses zombie . Ini tidak berbahaya: satu-satunya sumber daya yang dikonsumsi proses zombie adalah entri dalam tabel proses. Ini akan hilang ketika proses orang tua meninggal atau bereaksi terhadap kematian anaknya.

Anda dapat melihat apakah prosesnya adalah zombie dengan menggunakan top atau perintah berikut:

ps aux | awk '$8=="Z" {print $2}'
32
Josh

Periksa /var/log/kern.log Dan /var/log/dmesg (Atau yang setara) untuk mengetahui petunjuk. Dalam pengalaman saya, ini hanya terjadi pada saya ketika koneksi jaringan NFS mount tiba-tiba turun atau driver perangkat macet. Bisa terjadi jika hard drive rusak juga, saya percaya.

Anda dapat menggunakan lsof untuk melihat file perangkat apa yang telah dibuka oleh proses.

26
LawrenceC

Jika @ Maciej 's dan @ Gilles jawaban tidak menyelesaikan masalah Anda, dan Anda tidak mengenali prosesnya (dan menanyakan apa dengan distro Anda tidak dapat menjawab). Periksa Rootkit dan tanda-tanda lain yang Anda miliki dimiliki . Rootkit lebih dari mampu mencegah Anda membunuh prosesnya. Bahkan banyak yang mampu mencegah Anda melihatnya. Tetapi jika mereka lupa memodifikasi 1 program kecil, mereka mungkin terlihat (mis. Mereka memodifikasi top, tetapi tidak htop). Kemungkinan besar ini bukan masalahnya tetapi lebih baik aman daripada menyesal.

17
xenoterracide

Bunuh sebenarnya berarti mengirim sinyal. ada beberapa sinyal yang dapat Anda kirim. kill -9 adalah sinyal khusus.

Saat mengirim sinyal, aplikasi berurusan dengannya. jika tidak kernel mengatasinya. sehingga Anda dapat menjebak sinyal di aplikasi Anda.

Tapi aku bilang kill -9 itu spesial. Ini istimewa karena aplikasi tidak mendapatkannya. langsung ke kernel yang kemudian benar-benar membunuh aplikasi pada kesempatan pertama. dengan kata lain membunuhnya mati

kill -15 mengirimkan sinyal SIGTERM yang merupakan singkatan dari SIGNAL TERMINATE dengan kata lain memberitahu aplikasi untuk berhenti. Ini adalah cara yang ramah untuk memberi tahu aplikasi sudah saatnya untuk mematikan. tetapi jika aplikasi tidak merespons kill -9 akan membunuhnya.

jika kill -9 tidak berfungsi, itu mungkin berarti kernel Anda rusak. reboot sudah beres. Saya tidak ingat itu pernah terjadi.

11
DeveloperChris

Pertama, periksa apakah ini proses Zombie (yang sangat mungkin):

ps -Al

Anda akan melihat sesuatu seperti:

0 Z  1000 24589     1  0  80   0 -     0 exit   ?        00:00:00 soffice.bin <defunct>

(Perhatikan "Z" di sebelah kiri)

Jika kolom ke-5 bukan 1, berarti kolom tersebut memiliki proses induk. Coba bunuh id proses induk it.

Jika PPID = 1, JANGAN MEMBUNUHNYA !!, pikirkan perangkat atau proses lain mana yang mungkin terkait dengannya.

Misalnya, jika Anda menggunakan perangkat atau samba yang terpasang, cobalah untuk melepasnya. Itu mungkin melepaskan proses Zombie.

NOTE : If ps -Al (atau top) menunjukkan "D" dan bukan "Z", itu bisa terkait dengan pemasangan jarak jauh (seperti NFS). Dalam pengalaman saya, me-reboot adalah satu-satunya cara untuk pergi ke sana, tetapi Anda dapat memeriksa jawaban lain yang mencakup kasus itu secara lebih rinci.

11
lepe

Proses init kebal terhadap SIGKILL.

Ini juga berlaku untuk utas kernel, mis. "Proses" dengan PPID sama dengan 0.

10
jlliagre

Seperti yang disebutkan orang lain, proses dalam tidur yang tidak terputus tidak dapat segera dibunuh (atau, dalam beberapa kasus, sama sekali). Perlu dicatat bahwa keadaan proses lain, TASK_KILLABLE, ditambahkan untuk menyelesaikan masalah ini dalam skenario tertentu, terutama kasus umum di mana proses menunggu di NFS. Lihat http://lwn.net/Articles/288056/

Sayangnya saya tidak percaya ini digunakan di mana pun di kernel kecuali NFS.

10
user36054

Membuat skrip kecil yang banyak membantu saya memeriksanya!

Anda dapat menggunakannya untuk membunuh proses apa pun dengan nama yang diberikan di jalurnya (perhatikan ini !!) Atau Anda dapat membunuh proses apa pun dari pengguna yang diberikan menggunakan parameter "-u nama pengguna".

#!/bin/bash

if [ "$1" == "-u" ] ; then\n
        PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
        processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
        echo "############# Killing all processes of user: $2 ############################"
else
        echo "############# Killing processes by name: $1 ############################"
        processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi


for process in $processes ; do
        # "command" stores the entire commandline of the process that will be killed
        #it may be useful to show it but in some cases it is counter-productive
        #command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
        echo "Killing process: $process"
        echo ""
        kill -9 $process
done
6
user36035

Ada kasus di mana bahkan jika Anda mengirim kill -9 ke suatu proses, pid itu akan berhenti, tetapi proses restart secara otomatis (misalnya, jika Anda mencobanya dengan gnome-panel, ini akan dimulai ulang): mungkinkah itu terjadi di sini?

5
dag729

dari aslinya di sini :

periksa apakah strace menunjukkan sesuatu

strace -p <PID>

coba lampirkan ke proses dengan gdb

gdb <path to binary> <PID>

jika proses berinteraksi dengan perangkat yang dapat Anda lepas, lepaskan modul kernel untuk, atau putuskan secara fisik/cabut ... kemudian coba itu.

2
nmz787

Saya punya masalah seperti ini. Ini adalah program yang saya luncurkan dengan strace dan terputus dengan Ctrl + C. Itu berakhir dalam keadaan T (dilacak atau dihentikan). Saya tidak tahu bagaimana persisnya itu terjadi, tetapi itu tidak dapat dibunuh dengan SIGKILL.

Singkat cerita, saya berhasil membunuhnya dengan gdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit

Berdasarkan petunjuk dari jawaban gilles, saya memiliki proses bertanda "Z" ("dalam ps) yang menggunakan sumber daya sistem, bahkan memiliki port terbuka yang MENDENGARKAN dan Anda dapat terhubung dengannya. Ini setelah menjalankan kill -9 di atasnya. Induknya adalah "1" (mis. init) jadi secara teoritis seharusnya menghilang. Tapi tidak, itu tetap ada, meskipun tidak berlari.

Jadi dalam kasus saya itu adalah zombie tetapi masih memakan sumber daya ... FWIW.

Dan itu tidak bisa dibunuh oleh kill -9.

Dan orang tuanya adalah init tetapi tidak dituai (dibersihkan). Yaitu. init punya anak zombie.

Dan reboot tidak perlu untuk memperbaiki masalah. Meskipun reboot "akan berhasil" di sekitar masalah/membuatnya lebih cepat mati. Hanya tidak anggun, yang masih memungkinkan.

Dan itu adalah port DENGARKAN yang dimiliki oleh proses zombie (dan beberapa port lain juga seperti status CLOSE_WAIT menghubungkan localhost ke localhost). Dan itu bahkan masih menerima koneksi. Bahkan sebagai zombie. Saya kira itu belum sempat untuk membersihkan port sehingga koneksi masuk masih ditambahkan ke backlog mendengarkan port tcp, meskipun mereka tidak memiliki kesempatan untuk diterima.

Ternyata saya memiliki utas internal di dalamnya yang menjalankan "system call" (ioctl dalam contoh ini) yang membutuhkan beberapa jam untuk kembali (ini diharapkan). Rupanya sistem tidak dapat membunuhnya "sepanjang jalan" sampai ia kembali dari itu. Setelah beberapa jam dibersihkan dan soket semua secara otomatis ditutup, dll seperti yang diharapkan. Itu adalah waktu kematian yang merana!

Periksa juga dmesg untuk melihat apakah ada kepanikan kernel (mis. Bug kernel).

0
rogerdpack