Tidak bisa membunuh proses tidur

13

Sepertinya saya tidak bisa membunuh -9 proses yang dalam kondisi tidur interruptible (S):

[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip
[root@jupiter ~]# kill -9 16790
[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip

Bagaimana ini mungkin? Apakah ada cara untuk mematikan proses tanpa me-reboot?

BOUNTY: Saya benar-benar lebih tertarik pada penjelasan tentang bagaimana hal ini mungkin terjadi.

UPDATE: Ini adalah output dari lsof:

[root @ jupiter ~] # lsof -p 16790
PERINTAH PID PENGGUNA UKURAN PERANGKAT FD TIPE / OFF NAMA NAMA
yum 16790 root cwd DIR 1166.56842 4096 16886249 / home / del
yum 16790 root rtd DIR 253,0 4096 2 /
yum 16790 root txt REG 253,0 8304 336177337 / usr / bin / python
yum 16790 root mem REG 253,0 144776 346128569 /lib64/ld-2.5.so
yum 16790 root mem REG 253,0 1718232 346128573 /lib64/libc-2.5.so
yum 16790 root mem REG 253,0 23360 346128599 /lib64/libdl-2.5.so
yum 16790 root mem REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
yum 16790 root mem REG 253,0 615136 346128602 /lib64/libm-2.5.so
yum 16790 root mem REG 253,0 1244792 336171087 /usr/lib64/libpython2.4.so.1.0
yum 16790 root mem REG 253,0 95464 346128744 /lib64/libselinux.so.1
yum 16790 root mem REG 253,0 53448 346128750 /lib64/librt-2.5.so
yum 16790 root mem REG 253,0 13960 336187564 /usr/lib64/libplds4.so
yum 16790 root mem REG 253,0 58400 346128752 /lib64/libgcc_s-4.1.2-20080825.so.1
yum 16790 root mem REG 253,0 78384 336173796 /usr/lib64/libelf-0.137.so
yum 16790 root mem REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
yum 16790 root mem REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
yum 16790 root mem REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
yum 16790 root mem REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
yum 16790 root mem REG 253,0 17992 336187563 /usr/lib64/libplc4.so
yum 16790 root mem REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
yum 16790 root mem REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
yum 16790 root mem REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
yum 16790 root mem REG 253,0 1297136 336176959 / usr/lib64/libxml2.so.2.6.26
yum 16790 root mem REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
yum 16790 root mem REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
yum 16790 root mem REG 253,0 18152 346128670 /lib64/libutil-2.5.so
yum 16790 root mem REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
yum 16790 root mem REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
yum 16790 root mem REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
yum 16790 root mem REG 253,0 56434416 336184082 / usr / lib / locale / locale-arsip
yum 16790 root mem REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
yum 16790 root mem REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
yum 16790 root mem REG 253,0 96885 345638632 /usr/local/greenplum-loaders-3.3.0.0-build-3/lib/libz.so.1.2.3
yum 16790 root mem REG 253,0 247496 346128741 /lib64/libsepol.so.1
yum 16790 root mem REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
yum 16790 root mem REG 253,0 312336 336178453 / usr/lib64/libfreebl3.so
yum 16790 root mem REG 253,0 20240 336530067 /usr/lib64/python2.4/lib-dynload/timemodule.so
yum 16790 root mem REG 253,0 25048 336529953 /usr/lib64/python2.4/lib-dynload/stropmodule.so
yum 16790 root mem REG 253,0 18984 336530051 /usr/lib64/python2.4/lib-dynload/cStringIO.so
yum 16790 root mem REG 253,0 21816 336529943 /usr/lib64/python2.4/lib-dynload/collectionsmodule.so
yum 16790 root mem REG 253,0 52152 336530044 /usr/lib64/python2.4/lib-dynload/_socketmodule.so
yum 16790 root mem REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
yum 16790 root mem REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
yum 16790 root mem REG 253,0 1366912 346128748 /lib64/libcrypto.so.0.9.8e
yum 16790 root mem REG 253,0 190976 336187552 /usr/lib64/libgssapi_krb5.so.2.2
yum 16790 root mem REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
yum 16790 root mem REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
yum 16790 root mem REG 253,0 153720 336181723 /usr/lib64/libk5crypto.so.3.1
yum 16790 root mem REG 253,0 35984 336177832 /usr/lib64/libkrb5support.so.0.1
yum 16790 root mem REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
yum 16790 root mem REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
yum 16790 root mem REG 253,0 75384 336530050 /usr/lib64/python2.4/lib-dynload/cPickle.so
yum 16790 root mem REG 253,0 23736 336530064 /usr/lib64/python2.4/lib-dynload/structmodule.so
yum 16790 root mem REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
yum 16790 root mem REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
yum 16790 root mem REG 253,0 37944 336528952 /usr/lib64/python2.4/lib-dynload/itertoolsmodule.so
yum 16790 root mem REG 253,0 21528 336528929 /usr/lib64/python2.4/lib-dynload/_localemodule.so
yum 16790 root mem REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
yum 16790 root mem REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
yum 16790 root mem REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
yum 16790 root mem REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
yum 16790 root mem REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_randommodule.so
yum 16790 root mem REG 253,0 15320 336528948 /usr/lib64/python2.4/lib-dynload/fcntlmodule.so
yum 16790 root mem REG 253,0 32816 336530049 /usr/lib64/python2.4/lib-dynload/bz2.so
yum 16790 root mem REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
yum 16790 root mem REG 253,0 38696 336529819 /usr/lib64/python2.4/site-packages/cElementTree.so
yum 16790 root mem REG 253,0 42672 336530047 /usr/lib64/python2.4/lib-dynload/arraymodule.so
yum 16790 root mem REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
yum 16790 root mem REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
yum 16790 root mem REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
yum 16790 root mem REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
yum 16790 root mem REG 253,0 17496 336528966 /usr/lib64/python2.4/lib-dynload/selectmodule.so
yum 16790 root mem REG 253,0 46448 336528961 /usr/lib64/python2.4/lib-dynload/pyexpat.so
yum 16790 root mem REG 253,0 33896 336529820 /usr/lib64/python2.4/site-packages/_sqlite.so
yum 16790 root mem REG 253,0 41784 336530075 /usr/lib64/python2.4/site-packages/_sqlitecache.so
yum 16790 root mem REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
yum 16790 root mem REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
yum 16790 root mem REG 253,0 25464 336265457 /usr/lib64/gconv/gconv-modules.cache
yum 16790 root mem REG 253,0 66544 336528926 /usr/lib64/python2.4/lib-dynload/_cursesmodule.so
yum 16790 root mem REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
yum 16790 root mem REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
yum 16790 root mem REG 253,0 24576 236520047 /var/lib/rpm/__db.001
yum 16790 root mem REG 253,0 53880 346128424 /lib64/libnss_files-2.5.so
yum 16790 root mem REG 253,0 23736 346128408 /lib64/libnss_dns-2.5.so
yum 16790 root mem REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
yum 16790 root mem REG 253,0 663552 236520051 /var/lib/rpm/__db.003
yum 16790 root mem REG 253,0 769074 336174965 /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo
yum 16790 root 0u CHR 136,8 0t0 10 / dev / pts / 8 (dihapus)
yum 16790 root 1u CHR 136,8 0t0 10 / dev / pts / 8 (dihapus)
yum 16790 root 2u CHR 136,8 0t0 10 / dev / pts / 8 (dihapus)
yum 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 socket
yum 16790 root 4w REG 253,0 0 236522326 /var/log/yum.log
yum 16790 root 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
yum 16790 root 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (dihapus)
yum 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (dihapus)
yum 16790 root 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (dihapus)
yum 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (dihapus)
yum 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (dihapus)
yum 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (dihapus)
yum 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / Paket
yum 16790 root 13r REG 253,0 45056 236519438 / var / lib / rpm / Nama
yum 16790 root 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (ESTABLISHED)
yum 16790 root 15u IPv4 4675939 0t0 TCP jupiter.example.com:52708->freedom.itsc.cuhk.edu.hk:http (CLOSE_WAIT)
yum 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / Paket
yum 16790 root 17r REG 253,0 45056 236519438 / var / lib / rpm / Nama
yum 16790 root 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
yum 16790 root 20r FIFO 0,6 0t0 4676024 pipa
yum 16790 root 24w FIFO 0,6 0t0 4676024 pipa

linux centos process kill del
sumber

Bunuh proses lain yang memanipulasi kunci yang sama dan itu mungkin akan unjam.

David Schwartz

@ David - Saya tidak bisa membunuh semua proses yum dalam daftar proses di atas; mereka semua memiliki masalah yang sama.

del

Saya menghapus baris tambahan karena mereka tidak menambahkan informasi lagi dan mereka membuat lebih sulit untuk membaca posting Anda.

terdon

@slm - lsof menunjukkan soket TCP ke riksun.riken.go.jp:80 (ESTABLISHED) dan freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Saya kira itu bisa jadi itu?

del

@slm - Silakan lihat pertanyaan saya yang diperbarui.

del

18

Suatu proses dalam keadaan S atau D biasanya dalam panggilan sistem pemblokiran, seperti membaca atau menulis ke file atau jaringan, menunggu program yang dipanggil selesai, atau sambil menunggu di semaphores atau primitif sinkronisasi lainnya. Ini akan masuk ke kondisi tidur sambil menunggu.

Anda tidak dapat "membangunkannya" - ini hanya akan dilanjutkan ketika data / sumber daya yang ditunggu-tunggu tersedia. Ini semua normal dan diharapkan, dan hanya masalah ketika mencoba membunuhnya.

Anda dapat mencoba dan menggunakannya strace -p piduntuk mengetahui panggilan sistem mana yang saat ini terjadi untuk proses pid.

Dari wikipedia :

Kondisi tidur tanpa gangguan adalah kondisi tidur yang tidak akan langsung menangani sinyal. Ini akan terbangun hanya karena sumber daya menunggu tersedia atau setelah waktu habis terjadi selama menunggu itu (jika ditentukan saat ditidurkan). Itu sebagian besar digunakan oleh driver perangkat menunggu disk atau IO jaringan (input / output). Ketika proses tidur tanpa gangguan, sinyal yang terkumpul selama tidur akan diperhatikan ketika proses kembali dari panggilan sistem atau perangkap.

Sebuah proses yang diblokir dalam panggilan sistem adalah dalam keadaan tidak terputus, yang seperti namanya, benar-benar tidak terputus bahkan oleh root.

Biasanya, proses tidak dapat memblokir SIGKILL. Tetapi kode kernel dapat, dan memproses mengeksekusi kode kernel ketika mereka memanggil panggilan sistem, di mana kode Kernel memblokir semua sinyal. Jadi jika suatu sistem panggilan blok tanpa batas, mungkin secara efektif tidak ada cara untuk mematikan proses. SIGKILL hanya akan berlaku setiap kali proses panggilan sistem selesai

harrymc
sumber

2

Saya pikir hanya proses tidur tanpa gangguan yang dapat memblokir SIGKILL. Apakah proses tidur yang interupsi juga bisa? Jika demikian, apa perbedaan di antara mereka?

del

1

Kedua status S dan D pada hakekatnya tidak dapat diganggu, hanya karena terlalu rumit untuk diprogram dalam kernel dan karena di masa lalu mereka seharusnya hanya dalam durasi yang sangat singkat. Meskipun kernel telah berevolusi untuk memasukkan NFS dan kasus-kasus lain yang mungkin membutuhkan waktu lebih lama, sayangnya menunggu pemblokiran kernel tidak pernah dihapuskan.

harrymc

3

Menarik. Apakah Anda punya referensi untuk ini? Segala sesuatu yang dapat saya temukan dengan Google tampaknya mengatakan bahwa proses yang tidak terputus seharusnya tidak dapat mengabaikan SIGKILL.

del

1

Tampaknya bertentangan dengan semua yang saya baca tentang tidur yang dapat disela, dan saya sedikit skeptis bahwa saya telah menemukan beberapa perilaku yang tidak terdokumentasi. mis. Periksa 2 tautan berikut. Apakah saya salah mengerti sesuatu? (1) "Dalam tidur interruptible, proses dapat dibangunkan untuk pemrosesan sinyal." (2) "Jika sinyal dihasilkan untuk suatu proses dalam keadaan ini, maka operasi terputus dan proses dibangunkan oleh pengiriman sinyal."

del

1

Panggilan sistem interruptible atau tidak tergantung hanya pada bagaimana itu diprogram. Setelah satu ada di dalam kernel maka semuanya berjalan.

harrymc

10

Latar belakang tentang proses tidur

Anda mungkin ingin melihat pos Unix & Linux ini.

/unix/5642/what-if-kill-9-does-not-work

Khususnya jawaban ini, /unix//a/5648/7453 .

Kutipan dari pos itu

kill -9 (SIGKILL) selalu berfungsi, asalkan Anda memiliki izin untuk membunuh 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 membunuh -9 tidak dijamin untuk segera bekerja. 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 antri 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 dalam 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. (Tapi prosesnya akan dimatikan jika ia pernah menyelesaikan panggilan sistem.)

...

...

Saya sangat menyarankan untuk membaca sisa jawaban itu!

Membunuh proses yang diblokir oleh sumber daya (file atau jaringan)

Berikut adalah 2 hal untuk dicoba.

1. Menghapus file .pid yum

Apakah ada file kunci yum? Apa yang terjadi ketika Anda menghapus file kunci itu? Saya pikir itu mungkin memungkinkan untuk melanjutkan.

rm /var/run/yum.pid

2. Memaksa `CLOSE_WAIT`koneksi TCP yang menggantung ditutup

A CLOSE_WAITdijelaskan sebagai berikut:

CLOSE_WAIT Menunjukkan bahwa server telah menerima sinyal FIN pertama dari klien dan koneksi sedang dalam proses ditutup

Jadi ini pada dasarnya berarti bahwa itu adalah keadaan di mana socket sedang menunggu aplikasi untuk mengeksekusi close ()

Soket dapat dalam status CLOSE_WAIT tanpa batas waktu hingga aplikasi menutupnya. Skenario yang salah akan seperti kebocoran yang diajukan, server tidak dieksekusi tutup () pada soket yang mengarah ke soket close_wait

CATATAN: Kutipan dari situs web technet .

Ada 2 alat yang dapat Anda coba gunakan untuk mencapai ini.

Alat-alat ini bekerja dengan mensimulasikan pertukaran FIN-ACK-RST yang diperlukan agar koneksi TCP ditutup sepenuhnya.

Killcx bekerja dengan membuat paket SYN palsu dengan SeqNum palsu, menipu IP / port klien jarak jauh dan mengirimkannya ke server. Ini akan memotong proses anak yang akan menangkap respons server, mengekstrak 2 nilai ajaib dari paket ACK dan menggunakannya untuk mengirim paket RST palsu. Koneksi kemudian akan ditutup.

CATATAN: Kutipan dari situs web Killcx .

Menggunakan pemotong

Memotong koneksi khusus antara dua pasangan nomor ip / port yang diberikan.

# cutter ip-address-1 port-1 ip-address-2 port-2
% cutter 200.1.2.3 22 10.10.0.45 32451

Menggunakan Killcx

Memotong koneksi ke ip & port jarak jauh.

# killcx remote-ip-address:port
% killcx 120.121.122.123:1234

Sumber daya

serverfault - Cara menutup soket secara paksa saat menunggu

slm
sumber

Menghapus file kunci tidak berpengaruh.

del

1

Ini pada mesin produksi, dan sayangnya kedua alat ini memiliki dependensi yang tidak dapat saya instal. Saya memang mencoba /etc/init.d/networking restart dan tidak melakukan apa-apa. Sebenarnya, saya sekarang lebih tertarik untuk memahami mengapa ini bisa terjadi (karena saya tidak berpikir proses tidur yang interupsi dapat mengabaikan SIGKILL) daripada bagaimana saya bisa memperbaiki masalah ini.

del

Restart jaringan akan memiliki efek yang sama, sehingga pemblokiran pada I / O, jika itu sebenarnya proses yang sedang menunggu, ada di tempat lain.

slm

1

Anda dapat mencoba membunuh proses induknya. Gunakan ps untuk memeriksa:

ps xjf -C yum

Lalu kill -9setiap induk memproses.

terdon
sumber

Proses induk adalah init (kolom ke-5 di output saya).

del

1

Mungkin ada baiknya melekat pada proses dengan strace untuk melihat apakah itu benar-benar menganggur atau macet pada operasi IO. Mungkin memberikan petunjuk lebih lanjut untuk masalah ini.

strace -pPID

Dari apa yang saya baca tidak ada cara untuk mematikan proses ini selain me-reboot. Jika proses ini tidak memakan waktu cpu yang terlihat, tidak mungkin membuat dampak negatif ke server.

sumber

Terima kasih atas sarannya, tetapi proses induknya adalah init (lihat kolom ke-5 di output saya).

del

Re jawaban Anda yang direvisi, strace menempel pada proses tetapi tidak menghasilkan apa-apa.

del

1

Mungkinkah itu sedang menunggu proses anak? Saya suka ps fauxkarena itu akan memberi tahu Anda apakah ada proses anak, dan jika, yang Anda mungkin perlu membunuh.

Stefan Seidel
sumber

Tidak, proses ini tidak memiliki proses anak.

del