Ya 'öldür -9' işe yaramazsa?

Öldüremediğim bir süreç var kill -9 <pid>. Böyle bir durumda sorun ne, özellikle de bu sürecin sahibi olduğum için. Bu killseçeneğin hiçbir şeyinden kaçabileceğini düşünmemiştim .

kill -9( SIGKILL ) süreci öldürme izniniz olması kaydıyla her zaman çalışır. Temel olarak, ya süreç sizin tarafınızdan başlatılmalı ve hileli veya hükümsüz olmamalıdır, ya da kök olmalısınız. Bir istisna var: Kök bile PID 1'e ( initişlem) önemli bir sinyal gönderemiyor .

Ancak derhalkill -9 çalışması garanti edilmez . SIGKILL dahil tüm sinyaller asenkron olarak iletilir: çekirdeğin bunları iletmesi zaman alabilir. Genellikle, bir sinyalin iletilmesi, hedefin bir zaman dilimi alması için geçen süre kadar birkaç mikrosaniyeyi alır. Ancak, hedef sinyali bloke etmişse, hedef engeli kaldırıncaya kadar sinyal kuyruğa alınır.

Normalde, işlemler SIGKILL'i engelleyemez. Ancak çekirdek kodu sistem çağrıları çağırdığında çekirdek kodunu çalıştırabilir ve işler . Çekirdek kodu, sistem çağrısına ara verirken tüm sinyalleri engeller, çekirdeğin herhangi bir yerinde veya daha genel olarak bazı çekirdek değişmezlerinin ihlal edilmesine neden olan kötü oluşturulmuş bir veri yapısına neden olur. Bu nedenle (bir hata veya yanlış tasarım nedeniyle) bir sistem çağrısı süresiz olarak engellerse, süreci öldürmenin etkili bir yolu olmayabilir. (Ama süreç olacak hiç sistem çağrısı tamamlarsa öldürülebilir.)

Sistem çağrısında engellenen bir işlem kesintisiz uyku modundadır . psVeya topkomut (en Unix'lerde) devlet bunu gösterecektir D(başlangıçta “için d ISK” Bence).

Klasik kesintisiz uzun uyku durumu , sunucu yanıt vermediğinde dosyalara NFS üzerinden erişen süreçlerdir ; Modern uygulamalar kesintisiz bir uyku empoze etme eğilimindedir (örneğin Linux altında, intrmount seçeneği bir sinyalin NFS dosya erişimini kesmesine izin verir).

Bazen veya çıktıda işaretli Z(veya HLinux altında, ayrımın ne olduğunu bilmiyorum) girişleri görebilirsiniz . Bunlar teknik olarak süreç değil, süreç tablosuna girmekten başka bir şey olmayan zombi süreçleridir, böylece ebeveyn sürecin çocuğunun ölümünden haberdar olması sağlanır. Ana süreç dikkat ettiği zaman (veya öldüğü zaman) ortadan kalkarlar.pstop

Bazen bir süreç var ve aşağıdakiler nedeniyle öldürülemiyor:

• zombi olmak. Yani hangi ebeveynin çıkış durumunu okumadığı işlenir. Bu işlem, PID girişi dışında herhangi bir kaynak tüketmez. İçinde topZ sinyali var
• hatalı kesintisiz uyku. Olmaması gerekir, ancak bazen yapılan buggy çekirdek kodu ve / veya buggy donanımı ile birlikte. Tek yöntem yeniden başlatmak veya beklemektir. İçinde topD ile sinyal verilir.

Bir zombi sürecin varmış gibi geliyor . Bu zararsızdır: Bir zombi işleminin tükettiği tek kaynak, işlem tablosuna bir giriştir. Ebeveyn süreci öldüğünde veya çocuğunun ölümüne tepki gösterdiğinde ortadan kalkar.

topAşağıdaki komutu kullanarak işlemin bir zombi olup olmadığını görebilirsiniz :

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

Herhangi bir ipucu için sizin /var/log/kern.logve /var/log/dmesg(veya eşdeğerleriniz) olup olmadığını kontrol edin . Tecrübelerime göre bu bana ancak bir NFS montajının ağ bağlantısı aniden düştüğünde ya da bir aygıt sürücüsü kilitlendiğinde başıma geldi. Sanırım bir sabit disk de çökerse meydana gelebilir.

lsofİşlemin hangi cihaz dosyalarını açtığını görmek için kullanabilirsiniz .

@ Maciej 'in ve @ Gilles ' nun cevabı probleminizi çözmezse ve süreci tanımıyorsanız (ve dağıtımınızla ne olduğunu sormak cevap vermez). Rootkit en ve oldum başka işaretler edin olunan . Bir rootkit, süreci öldürmenizi engellemekten daha fazlasını sağlar. Aslında birçoğu onları görmenizi engelleyebilir. Ancak 1 küçük programı değiştirmeyi unuturlarsa, farkedilebilirler (örneğin, değiştirdiler topama değil htop). Büyük olasılıkla durum bu değil, üzgünümden daha güvenli.

Öldürmek aslında bir sinyal yollamak demektir. gönderebileceğiniz birden fazla sinyal var. kill -9 özel bir sinyaldir.

Bir sinyal gönderirken uygulama bununla ilgilenir. eğer çekirdek bununla uğraşmazsa. Böylece uygulamanızdaki bir sinyali yakalayabilirsiniz.

Ama öldür -9'un özel olduğunu söyledim. Uygulamanın alamadığı özel bir şey. doğruca çekirdeğe gider ve daha sonra ilk fırsatta uygulamayı gerçekten öldürür. başka bir deyişle, onu öldürür

kill -15, SİNYAL TERMİNAT'ın anlamına gelen SIGTERM sinyalini gönderir, başka bir deyişle, uygulamanın bırakmasını söyler. Bu, bir uygulamanın kapanma zamanının geldiğini söylemenin kolay yoludur. Ancak uygulama yanıt vermiyorsa kill -9 onu öldürür.

öldür -9 işe yaramazsa, muhtemelen çekirdeğiniz tükenir demektir. bir yeniden başlatma sırası var. Bunun olduğunu asla hatırlayamıyorum.

İlk önce, bunun bir Zombie işlemi olup olmadığını kontrol edin (ki bu çok mümkün):

ps -Al

Gibi bir şey göreceksiniz:

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

(Soldaki "Z" yi not edin)

5. sütun 1 değilse, bunun bir üst süreci olduğu anlamına gelir. Bu ana işlem kimliğini öldürmeyi deneyin .

Eğer PPID = 1 ise, ÖLMEYİN! Başka hangi cihazların veya işlemlerin onunla ilişkili olabileceğini düşünün.

Örneğin, monte edilmiş bir cihaz veya samba kullanıyorsanız, bağlantısını kesmeyi deneyin. Bu Zombie işlemini serbest bırakabilir.

NOT : ps -Al(veya top) "Z" yerine "D" gösteriyorsa, uzaktan montajla (NFS gibi) ilgili olabilir. Tecrübelerime göre, yeniden başlatma oraya gitmek için tek yol, ancak bu durumu kapsayan diğer cevapları daha ayrıntılı olarak kontrol edebilirsiniz.

İnit işlemi SIGKILL'e karşı bağışıklık kazanmıştır.

Bu aynı zamanda çekirdek dişleri için de geçerlidir, yani 0'a eşit bir PPID ile "işlemler".

Diğerlerinin de belirttiği gibi, kesintisiz uykudaki bir süreç hemen (veya bazı durumlarda hiç) öldürülemez. Bu sorunu belirli senaryolarda, özellikle sürecin NFS'de beklediği genel durum için çözmek için TASK_KILLABLE adlı başka bir işlem durumunun eklendiğini belirtmekte fayda var. Bkz http://lwn.net/Articles/288056/

Ne yazık ki, bunun çekirdeğin herhangi bir yerinde kullanıldığına inanmıyorum ama NFS.

Bana bir göz atmam için çok yardımcı olan küçük bir senaryo yaptım!

Belirli bir isimdeki herhangi bir işlemi yolunda öldürmek için kullanabilirsiniz (buna dikkat edin !!) Veya "-u username" parametresini kullanarak belirli bir kullanıcının herhangi bir işlemini öldürebilirsiniz.

#!/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

Bir sürece bir öldür -9 gönderseniz bile, bu ödemenin durduğu, ancak işlemin otomatik olarak yeniden başlatıldığı durumlar var (örneğin, denerseniz gnome-panel, yeniden başlatılacak): bu durumda olabilir mi?

dan aslen burada :

Strace bir şey gösterip göstermediğini kontrol et

strace -p <PID>

gdb ile işleme eklemeyi deneyin

gdb <path to binary> <PID>

İşlem, sökebildiğiniz bir cihazla etkileşime giriyorsa, çekirdek modülünü çıkarın veya fiziksel olarak bağlantısını kesin / çıkarın ... sonra bunu deneyin.

Bu konuda bir sorunum vardı. Bu + straceile başlattığım ve ara verdiğim bir programdı . Sonunda (izlendi veya durdu) bir duruma geldi. Tam olarak nasıl olduğunu bilmiyorum, ama katlanılabilir değildi .CtrlCTSIGKILL

Uzun lafın kısası, onu öldürmeyi başardım gdb:

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

Gilles'in cevabından gelen bir ipucuna dayanarak, <defunct>sistem kaynaklarını kullanan üstte ( ps cinsinden) "Z" işaretli bir işlem vardı, LISTEN'ing olan bir bağlantı noktası açık bile oldu ve o bağlantı noktasına bağlanabiliyordunuz. Bu, kill -9üzerinde bir çalıştırdıktan sonra oldu . Onun ebeveyn "1" (yani init) öyleydi, bu yüzden teorik olarak sadece tekrarlanmalı ve kaybolmalı. Ama değildi, etrafta dolaşıyordu, koşmasa da "ölmüyordu"

Yani benim durumumda zombi ama yine de kaynakları tüketiyordu ... FWIW.

Ve herhangi sayısına göre killable değildi kill -9's

Ve onun ebeveyni vardı, initancak ulaşılmıyordu (temizlendi). Yani initbir zombi çocuğu vardı.

Ve sorunu çözmek için yeniden başlatma gerekli değildi. Bir yeniden başlatma sorunu etrafında "işe yaramazdı" olsa da / bunu daha hızlı kapatmayı başardı. Sadece zarif değil, yine de mümkündü.

Ve bir zombi işlemine ait bir LISTEN limanıydı (ve ayrıca, localhost'u localhost'a bağlı CLOSE_WAIT statüsüne benzeyen birkaç başka liman). Ve hala bağlantıları bile kabul ediyordu. Bir zombi olarak bile. Sanırım limanları temizlemek için etrafta dolaşmadı, bu yüzden kabul edilme şansı olmamasına rağmen, tcp dinleme portunun backlog'una gelen bağlantılar hala eklendi.

Yukarıdakilerin çoğu interweblerde çeşitli yerlerde "imkansız" olarak belirtilmiştir.

İçinde, bir "sistem çağrısı" (bu örnekte ioctl) yürüten ve bu işlemin geri dönüşünün birkaç saat sürdüğü (bu beklenen davranıştı) içsel bir iş parçacığım olduğu anlaşılıyor. Görünüşe göre sistem ioctlçağrıdan geri dönene kadar süreci "tamamen" öldüremiyor , sanırım çekirdek toprağa giriyor. Birkaç saat sonra geri döndü, işler düzeldi ve yuvalar beklendiği gibi otomatik olarak kapatıldı. Ölüm sırasındaki biraz sıkıcı zaman! Çekirdek sabırla onu öldürmeyi bekliyordu.

Yani OP'ye cevap vermek için bazen beklemek zorundasın. Uzun zaman. O zaman öldürme sonunda alacak.

Ayrıca bir çekirdek paniği olup olmadığını görmek için dmesg'i kontrol edin (örn. Çekirdek böceği).