Uyku sürecini öldüremiyorum


13

Kesintisiz uyku (S) durumunda olan bir işlemi -9'u öldürebilecek gibi görünmüyorum:

[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

Bu nasıl mümkün olabilir? Yeniden başlatmadan süreci öldürmenin bir yolu var mı?

BOUNTY: Bunun gerçekleşmesinin nasıl mümkün olabileceğine dair bir açıklama ile daha çok ilgileniyorum.

GÜNCELLEME: Bu lsof çıktısıdır:

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

Aynı kilidi manipüle eden diğer işlemleri öldürün ve muhtemelen sıkışacaktır.
David Schwartz

@David - Yukarıdaki işlem listesindeki yum işlemlerinden hiçbirini öldüremiyorum; hepsinin aynı sorunu var.
del

Ek satırları kaldırdım çünkü daha fazla bilgi eklemiyorlardı ve yayınınızı okumayı zorlaştırıyorlardı.
terdon

@slm - lsof riksun.riken.go.jp:80 (KURULDU) ve freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT) için TCP soketlerini gösterir. Sanırım bu olabilir mi?
del

@slm - Lütfen güncellenmiş soruma bakın.
del

Yanıtlar:


18

S veya D durumundaki bir işlem genellikle bir dosya veya ağa okuma veya yazma, çağrılan bir programın bitmesini beklemek veya semaforları veya diğer senkronizasyon ilkelerini beklemek gibi bir engelleme sistem çağrısındadır. Beklerken uyku durumuna geçecektir.

"Uyandıramazsınız" - yalnızca beklediği veri / kaynak kullanılabilir olduğunda devam eder. Bu normal ve beklenen bir şey ve sadece onu öldürmeye çalışırken bir sorun.

strace -p pidİşlem pid için şu anda hangi sistem çağrısının yapıldığını bulmak için deneyebilir ve kullanabilirsiniz .

Gönderen wikipedia :

Kesintisiz uyku durumu, bir sinyali hemen işlemeyecek bir uyku durumudur. Beklenen bir kaynağın kullanılabilir olması veya bu bekleme sırasında bir mola verildikten sonra (uyku moduna alındığında belirtilirse) uyanacaktır. Çoğunlukla disk veya ağ GÇ'sini (giriş / çıkış) bekleyen aygıt sürücüleri tarafından kullanılır. İşlem kesintisiz bir şekilde uyurken, sistem çağrısından veya tuzağından geri döndüğünde uyku sırasında biriken sinyaller fark edilir.

Sistem çağrısında engellenen bir süreç, adından da anlaşılacağı gibi, kök tarafından bile gerçekten kesintisiz olan kesintisiz uyku durumundadır.

Normalde işlemler SIGKILL'i engelleyemez. Ancak çekirdek kodu sistem çağrılarını çağırdıklarında çekirdek kodunu yürütebilir ve işlem sırasında çekirdek kodu tüm sinyalleri engeller. Dolayısıyla, bir sistem çağrısı süresiz olarak engellenirse, süreci öldürmenin etkili bir yolu olmayabilir. SIGKILL sadece işlem sistem çağrısını tamamladığında etkili olur.


2
Sadece kesintisiz uyku süreçlerinin SIGKILL'i engelleyebileceğini düşündüm. Kesilebilir uyku süreçleri de mümkün müdür? Eğer öyleyse, aralarındaki fark nedir?
del

1
Hem S hem de D durumları kesintisiz olarak, çünkü çekirdekte programlamak için çok karmaşık olduğu ve geçmişte çok kısa süreleri olması gerektiği için. Çekirdek, NFS'yi ve çok daha uzun sürebilen diğer vakaları içerecek şekilde evrimleşmiş olmasına rağmen, çekirdek engelleme beklemeleri maalesef asla kaldırılmadı.
harrymc

3
İlginç. Bunun için referansınız var mı? Google ile bulabildiğim her şey, kesilebilir süreçlerin SIGKILL'i göz ardı etmemesi gerektiğini söylüyor.
del

1
Kesintisiz uykular hakkında okuduğum her şeyle çelişiyor gibi görünüyor ve belgelenmemiş davranışlara tökezlediğim konusunda biraz şüpheliyim. Aşağıdaki 2 bağlantıyı kontrol edin. Bir şeyi yanlış mı anlıyorum? (1) "Kesintili bir uykuda, sinyallerin işlenmesi için işlem uyandırılabilir." (2) "Bu durumdaki bir işlem için bir sinyal üretilirse, işlem kesilir ve işlem bir sinyalin iletilmesiyle uyandırılır."
del

1
Bir sistem çağrısı kesilebilir veya yalnızca nasıl programlandığına bağlı değildir. Biri çekirdeğin içine girdikten sonra her şey gider.
harrymc

10

Uyku sürecinin arka planı

Bu Unix ve Linux yayınına bir göz atmak isteyebilirsiniz.

Özellikle bu cevap, /unix//a/5648/7453 .

Bu yayından alıntı

kill -9 (SIGKILL) her zaman çalışır, eğer süreci öldürme izniniz varsa. Temel olarak, işlem sizin tarafınızdan başlatılmalı ve setuid veya setgid olmamalı veya kök olmalısınız. Bir istisna vardır: Kök bile PID 1'e (başlatma işlemi) ölümcül bir sinyal gönderemez.

Ancak kill -9'un hemen çalışması garanti edilmez. SIGKILL de dahil olmak üzere tüm sinyaller eşzamansız olarak gönderilir: çekirdek bunları iletmek için zaman alabilir. Genellikle, bir sinyalin iletilmesi en fazla birkaç mikrosaniye sürer, sadece hedefin bir zaman dilimi elde etmesi için geçen süre. Ancak, hedef sinyali bloke ettiyse, hedef engellemesini kaldırana kadar sinyal kuyruğa alınır.

Normalde işlemler SIGKILL'i engelleyemez. Ancak çekirdek kodu, sistem çağrılarını çağırdıklarında çekirdek kodunu yürütebilir ve işler. Çekirdek kodu, sistem çağrısını kesintiye uğrattığında tüm sinyalleri engeller, çekirdeğin bir yerinde kötü şekillendirilmiş bir veri yapısına veya daha genel olarak bazı çekirdek değişmezlerinin ihlal edilmesine neden olur. Bu nedenle (bir hata veya yanlış tasarım nedeniyle) bir sistem çağrısı süresiz olarak engellenirse, süreci öldürmenin etkili bir yolu olmayabilir. (Ancak sistem çağrısını tamamlarsa süreç öldürülecektir.)

...

...

Bu cevabın geri kalanını okumanızı tavsiye ederim!

Bir kaynak (dosya veya ağ) tarafından engellenen bir işlemi öldürme

İşte denenecek 2 şey.

1. yum'un .pid dosyasını kaldırma

Mevcut bir yum kilit dosyası var mı? Bu kilit dosyasını kaldırdığınızda ne olur? Bunun devam etmesine izin verebileceğini düşünüyorum.

rm /var/run/yum.pid

2. Asma CLOSE_WAITTCP bağlantılarını zorlama

A CLOSE_WAIT, aşağıdaki gibi tarif edilir:

CLOSE_WAIT Sunucunun istemciden ilk FIN sinyalini aldığını ve bağlantının kapalı olduğunu belirtir.

Yani bu aslında onun soketin uygulamanın close () yürütmesini beklediği bir durum olduğu anlamına gelir.

Bir soket, uygulama kapanana kadar süresiz olarak CLOSE_WAIT durumunda olabilir. Hatalı senaryolar dosya tanımlayıcı sızıntısı gibi olabilir, sunucu soket üzerinde close_wait soketlerinin yığılmasına neden olacak şekilde close () yürütülmez

NOT: Technet web sitesinden alıntı .

Bunu başarmak için kullanabileceğiniz 2 araç vardır.

Bu araçlar , TCP bağlantısının tamamen kapatılması için gerekli olan FIN-ACK-RST değişimini simüle ederek çalışır .

Killcx, sahte bir SeqNum ile sahte bir SYN paketi oluşturarak, uzak istemci IP / portunu taklit ederek ve sunucuya göndererek çalışır. Sunucu yanıtını yakalayacak, 2 sihirli değeri ACK paketinden çıkaracak ve bunları sahte bir RST paketi göndermek için kullanacak bir alt işlemi çatallayacaktır. Bağlantı daha sonra kapatılacaktır.

NOT: Killcx web sitesinden alıntı .

Kesici kullanarak

Verilen iki ip / port numarası çifti arasındaki özel bağlantıyı keser.

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

Killcx Kullanımı

Uzak ip ve bağlantı noktasına bağlantıları keser.

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

kaynaklar


Kilit dosyasının kaldırılmasının bir etkisi olmamıştır.
del

1
Bu bir üretim makinesinde ve maalesef bu iki aracın yükleyemediğim bağımlılıkları var. /Etc/init.d/networking restart komutunu denedim ve hiçbir şey yapmadı. Aslında, bu sorunun nasıl çözülebileceğinden ziyade, bunun neden olabileceğini anlamakla daha fazla ilgileniyorum (kesilebilir uyku süreçlerinin SIGKILL'i göz ardı edebileceğini düşünmedim).
del

Ağın yeniden başlatılması aynı etkiye sahip olacaktır, bu nedenle G / Ç üzerindeki engelleme, aslında sürecin beklediği şeyse, başka bir yerde yatar.
slm

1

Üst işlemi öldürmeyi deneyebilirsiniz. Kontrol etmek için ps kullanın:

ps xjf -C yum

Sonra kill -9herhangi bir üst süreç.


Üst işlem init (çıktımdaki 5. sütun).
del

1

Bir G / Ç işleminde gerçekten boşta mı yoksa sıkışmış mı olduğunu görmek için sürece strace ile bağlanmaya değer olabilir. Belki konuyla ilgili daha fazla ipucu verebilir.

strace -pPID

Okuduğum kadarıyla, bu işlemi yeniden başlatmanın dışında öldürmenin bir yolu yok. İşlem gözle görülür bir cpu süresi tüketmiyorsa, sunucu üzerinde olumsuz bir etki yaratması olası değildir.


Öneri için teşekkürler, ancak üst işlem başlatılıyor (çıktımdaki 5. sütuna bakın).
del

Revize cevabınızı tekrarlayın, strace sürece bağlanır, ancak hiçbir şey çıkarmaz.
del

1

Bir çocuk süreci bekliyor olabilir mi? Seviyorum ps fauxçünkü size çocuk süreçleri olup olmadığını ve öldürmeniz gerekebileceğini söyleyecektir.


Hayır, bu sürecin alt süreci yoktur.
del
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.