Nie można zabić snu

13

Wydaje mi się, że nie jestem w stanie zabić -9 procesu, który jest w stanie przerywanego snu (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

Jak to jest możliwe? Czy jest jakiś sposób, aby zabić proces bez ponownego uruchamiania?

BOUNTY: Naprawdę bardziej interesuje mnie wyjaśnienie, jak to możliwe.

AKTUALIZACJA: To jest wynik lsof:

[root @ jupiter ~] # lsof -p 16790
POLECENIE PID UŻYTKOWNIK TYP FD ROZMIAR URZĄDZENIA / WYŁĄCZ NAZWA NAZWY
mnisz 16790 root cwd DIR 1166,56842 4096 16886249 / home / del
mnisz 16790 root rtd DIR 253,0 4096 2 /
mnisz 16790 root txt REG 253,0 8304 336177337 / usr / bin / python
mnisz 16790 root mem REG 253,0 144776 346128569 /lib64/ld-2.5.so
mniam 16790 root mem REG 253,0 1718232 346128573 /lib64/libc-2.5.so
mniam 16790 root mem REG 253,0 23360 346128599 /lib64/libdl-2.5.so
mnisz 16790 root mem REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
mnisz 16790 mem root REG 253,0 615136 346128602 /lib64/libm-2.5.so
mnisz 16790 root mem REG 253,0 1244792 336171087 /usr/lib64/libpython2.4.so.1.0
mniam 16790 root mem REG 253,0 95464 346128744 /lib64/libselinux.so.1
mnisz 16790 root mem REG 253,0 53448 346128750 /lib64/librt-2.5.so
mniam 16790 root mem REG 253,0 13960 336187564 /usr/lib64/libplds4.so
mnisz 16790 root mem REG 253,0 58400 346128752 /lib64/libgcc_s-4.1.2-20080825.so.1
mniam 16790 root mem REG 253,0 78384 336173796 /usr/lib64/libelf-0.137.so
mniam 16790 root mem REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
mniszę 16790 root mem REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
mniam 16790 root mem REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
mnisz 16790 korzeń mem REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
mniam 16790 root mem REG 253,0 17992 336187563 /usr/lib64/libplc4.so
mniszę 16790 root mem REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
mniszę 16790 mem root REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
mnisz 16790 root mem REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
mniszę 16790 root mem REG 253,0 1297136 336176959 /usr/lib64/libxml2.so.2.6.26
mnisz 16790 root mem REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
mniam 16790 root mem REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
mniszę 16790 root mem REG 253,0 18152 346128670 /lib64/libutil-2.5.so
mnisz 16790 root mem REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
mnisz 16790 root mem REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
mnisz 16790 mem root REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
mnisz 16790 root mem REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
mnisz 16790 root mem REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
mniam 16790 root mem REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
mnisz 16790 root mem REG 253,0 96885 345638632 /usr/local/greenplum-loaders-3.3.0.0-build-3/lib/libz.so.1.2.3
mnisz 16790 korzeń mem REG 253,0 247496 346128741 /lib64/libsepol.so.1
mnisz 16790 root mem REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
mniam 16790 root mem REG 253,0 312336 336178453 /usr/lib64/libfreebl3.so
mniam 16790 root mem REG 253,0 20240 336530067 /usr/lib64/python2.4/lib-dynload/timemodule.so
mniam 16790 root mem REG 253,0 25048 336529953 /usr/lib64/python2.4/lib-dynload/stropmodule.so
mnisz 16790 root mem REG 253,0 18984 336530051 /usr/lib64/python2.4/lib-dynload/cStringIO.so
mniam 16790 root mem REG 253,0 21816 336529943 /usr/lib64/python2.4/lib-dynload/collectionsmodule.so
mniam 16790 root mem REG 253,0 52152 336530044 /usr/lib64/python2.4/lib-dynload/_socketmodule.so
mniam 16790 root mem REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
mnisz 16790 mem mem root REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
mniam 16790 root mem REG 253,0 1366912 346128748 /lib64/libcrypto.so.0.9.8e
mnisz 16790 root mem REG 253,0 190976 336187552 /usr/lib64/libgssapi_krb5.so.2.2
mniszę 16790 root mem REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
mnisz 16790 root mem REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
mniam 16790 root mem REG 253,0 153720 336181723 /usr/lib64/libk5crypto.so.3.1
mnisz 16790 root mem REG 253,0 35984 336177832 /usr/lib64/libkrb5support.so.0.1
mnisz 16790 root mem REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
mnisz 16790 root mem REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
mnisz 16790 root mem REG 253,0 75384 336530050 /usr/lib64/python2.4/lib-dynload/cPickle.so
mnisz 16790 root mem REG 253,0 23736 336530064 /usr/lib64/python2.4/lib-dynload/structmodule.so
mnisz 16790 root mem REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
mnisz 16790 root mem REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
mniam 16790 root mem REG 253,0 37944 336528952 /usr/lib64/python2.4/lib-dynload/itertoolsmodule.so
mniam 16790 root mem REG 253,0 21528 336528929 /usr/lib64/python2.4/lib-dynload/_localemodule.so
mniszę 16790 root mem REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
mnisz 16790 root mem REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
mniam 16790 root mem REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
mnisz 16790 root mem REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
mnisz 16790 root mem REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_randommodule.so
mnisz 16790 root mem REG 253,0 15320 336528948 /usr/lib64/python2.4/lib-dynload/fcntlmodule.so
mnisz 16790 root mem REG 253,0 32816 336530049 /usr/lib64/python2.4/lib-dynload/bz2.so
mnisz 16790 root mem REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
mnisz 16790 root mem REG 253,0 38696 336529819 /usr/lib64/python2.4/site-packages/cElementTree.so
mniam 16790 root mem REG 253,0 42672 336530047 /usr/lib64/python2.4/lib-dynload/arraymodule.so
mnisz 16790 root mem REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
mniam 16790 root mem REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
mniam 16790 root mem REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
mniam 16790 root mem REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
mnisz 16790 root mem REG 253,0 17496 336528966 /usr/lib64/python2.4/lib-dynload/selectmodule.so
mniam 16790 root mem REG 253,0 46448 336528961 /usr/lib64/python2.4/lib-dynload/pyexpat.so
mnisz 16790 root mem REG 253,0 33896 336529820 /usr/lib64/python2.4/site-packages/_sqlite.so
mniam 16790 root mem REG 253,0 41784 336530075 /usr/lib64/python2.4/site-packages/_sqlitecache.so
mniam 16790 root mem REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
mniam 16790 root mem REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
mnisz 16790 root mem REG 253,0 25464 336265457 /usr/lib64/gconv/gconv-modules.cache
mniam 16790 root mem REG 253,0 66544 336528926 /usr/lib64/python2.4/lib-dynload/_cursesmodule.so
mnisz 16790 root mem REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
mniam 16790 root mem REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
mnisz 16790 root mem REG 253,0 24576 236520047 /var/lib/rpm/__db.001
mnisz 16790 root mem REG 253,0 53880 346128424 /lib64/libnss_files-2.5.so
mniam 16790 root mem REG 253,0 23736 346128408 /lib64/libnss_dns-2.5.so
mnisz 16790 root mem REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
mnisz 16790 root mem REG 253,0 663552 236520051 /var/lib/rpm/__db.003
mnisz 16790 root mem REG 253,0 769074 336174965 /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo
mnisz 16790 korzeń 0u CHR 136,8 0t0 10 / dev / pts / 8 (usunięty)
mnisz 16790 korzeń 1u CHR 136,8 0t0 10 / dev / pts / 8 (usunięty)
mnisz 16790 korzeń 2u CHR 136,8 0t0 10 / dev / pts / 8 (usunięty)
mniam 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 gniazdo
mnisz 16790 root 4w REG 253,0 0 236522326 /var/log/yum.log
mnisz 16790 root 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
mnisz 16790 root 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (usunięty)
mnisz 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (usunięty)
mnisz 16790 korzeń 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (usunięty)
mnisz 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (usunięty)
mnisz 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (usunięty)
mnisz 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (usunięty)
mniam 16790 korzeń 12r REG 253,0 65204224 236519434 / var / lib / rpm / Pakiety
mnisz 16790 root 13r REG 253,0 45056 236519438 / var / lib / rpm / Name
mniam 16790 root 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (ESTABLISHED)
mniam 16790 root 15u IPv4 4675939 0t0 TCP jupiter.example.com:52708->freedom.itsc.cuhk.edu.hk:http (CLOSE_WAIT)
mniam 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / Packages
mnisz 16790 root 17r REG 253,0 45056 236519438 / var / lib / rpm / Name
mnisz 16790 korzeń 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
mniam 16790 korzeń 20r FIFO 0,6 0t0 4676024 rura
mniam 16790 rura 24w FIFO 0,6 0t0 4676024 rura
linux  centos  process  kill 
— del
źródło
Zabij inne procesy, które manipulują tym samym zamkiem, a prawdopodobnie się odblokuje.
— David Schwartz
@David - Nie mogę zabić żadnego z yum procesów na powyższej liście procesów; wszyscy mają ten sam problem.
— del
Usunąłem dodatkowe wiersze, ponieważ nie dodawali już żadnych informacji i utrudniali czytanie Twojego postu.
— terdon
@slm - lsof pokazuje gniazda TCP do riksun.riken.go.jp:80 (ESTABLISHED) i freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Myślę, że to może być to?
— del
@slm - Zobacz moje zaktualizowane pytanie.
— del

Odpowiedzi:

18

Proces w stanie S lub D zwykle znajduje się w blokującym wywołaniu systemowym, takim jak odczyt lub zapis do pliku lub sieci, oczekiwanie na zakończenie wywoływanego programu lub oczekiwanie na semafory lub inne operacje podstawowe synchronizacji. Przejdzie w stan uśpienia podczas oczekiwania.

Nie możesz „obudzić” - nastąpi to tylko wtedy, gdy dane / zasób, na który czeka, stają się dostępne. To wszystko jest normalne i oczekiwane, i tylko problem przy próbie zabicia go.

Możesz spróbować użyć, strace -p pidaby dowiedzieć się, jakie jest obecnie wywołanie systemowe dla procesu pid.

Z wikipedii :

Nieprzerwany stan uśpienia to stan uśpienia, który nie obsłuży sygnału od razu. Budzi się tylko w wyniku udostępnienia zasobu oczekującego lub gdy upłynie limit czasu podczas tego oczekiwania (jeśli jest określony, gdy zostanie uśpiony). Jest używany głównie przez sterowniki urządzeń czekające na dyskowe lub sieciowe IO (wejście / wyjście). Gdy proces śpi nieprzerwanie, sygnały nagromadzone podczas snu zostaną zauważone, gdy proces powróci z wywołania systemowego lub pułapki.

Proces zablokowany w wywołaniu systemowym znajduje się w nieprzerwanym trybie uśpienia, który, jak sama nazwa wskazuje, jest naprawdę nieprzerwany nawet przez rootowanie.

Zwykle procesy nie mogą blokować SIGKILL. Ale kod jądra może i procesy wykonują kod jądra, gdy wywołują wywołania systemowe, podczas których kod jądra blokuje wszystkie sygnały. Więc jeśli systemowe wywołanie blokuje się na czas nieokreślony, może nie być skutecznie zabić procesu. SIGKILL zacznie obowiązywać tylko wtedy, gdy proces zakończy wywołanie systemowe.

— harrymc
źródło
2
Myślałem, że tylko nieprzerwane procesy snu były w stanie zablokować SIGKILL. Czy są w stanie również przerwać procesy snu? Jeśli tak, jaka jest między nimi różnica?
— del
1
Zarówno stany S, jak i D są w rzeczywistości nieprzerwane, po prostu dlatego, że są zbyt skomplikowane, aby programować je w jądrze, a ponieważ w przeszłości miały one trwać bardzo krótko. Chociaż jądro ewoluowało i obejmuje NFS oraz inne przypadki, które mogą trwać znacznie dłużej, oczekiwania na blokowanie jądra niestety nigdy nie zostały zniesione.
— harrymc
3
Ciekawy. Czy masz na to jakieś referencje? Wszystko, co mogę znaleźć w Google, wydaje się mówić, że przerywalne procesy nie powinny być w stanie zignorować SIGKILL.
— del
1
Wydaje się to zaprzeczać wszystkiemu, co przeczytałem o przerywanych snach, i jestem trochę sceptyczny, że natknąłem się na jakieś nieudokumentowane zachowanie. np. Sprawdź następujące 2 linki. Czy coś nie rozumiem? (1) „W trybie przerywanego uśpienia proces może zostać obudzony w celu przetworzenia sygnałów.” (2) „Jeśli sygnał jest generowany dla procesu w tym stanie, wówczas operacja jest przerywana, a proces jest budzony przez dostarczenie sygnału.”
— del
1
Wywołanie systemowe jest przerywane lub nie zależy tylko od tego, jak zostało zaprogramowane. Gdy ktoś znajdzie się w jądrze, wszystko się kończy.
— harrymc
10

Tło na temat procesu spania

Możesz rzucić okiem na ten post w systemach Unix i Linux.

W szczególności ta odpowiedź /unix//a/5648/7453 .

Fragment tego postu

kill -9 (SIGKILL) zawsze działa, pod warunkiem, że masz pozwolenie na zabicie procesu. Zasadniczo albo proces musi zostać rozpoczęty przez Ciebie i nie może być ustawiony jako setuid lub setgid, albo musisz być rootem. Jest jeden wyjątek: nawet root nie może wysłać fatalnego sygnału do PID 1 (proces init).

Jednak zabicie -9 nie gwarantuje natychmiastowej pracy. Wszystkie sygnały, w tym SIGKILL, są dostarczane asynchronicznie: jądro może zająć trochę czasu, aby je dostarczyć. Zazwyczaj dostarczenie sygnału zajmuje najwyżej kilka mikrosekund, tyle ile potrzeba, aby cel otrzymał przedział czasu. Jeśli jednak cel zablokował sygnał, sygnał będzie w kolejce, dopóki cel go nie odblokuje.

Zwykle procesy nie mogą blokować SIGKILL. Ale kod jądra może i procesy wykonują kod jądra, gdy wywołują wywołania systemowe. Kod jądra blokuje wszystkie sygnały, gdy przerwanie wywołania systemowego spowodowałoby źle sformułowaną strukturę danych gdzieś w jądrze, lub bardziej ogólnie, naruszenie niektórych niezmienników jądra. Jeśli więc (z powodu błędu lub błędnego zaprojektowania) wywołanie systemowe zostanie zablokowane na czas nieokreślony, może nie być skutecznie zabić tego procesu. (Ale proces zostanie zabity, jeśli kiedykolwiek zakończy wywołanie systemowe).

...

...

Gorąco polecam przeczytanie reszty tej odpowiedzi!

Zabicie procesu zablokowanego przez zasób (plik lub sieć)

Oto 2 rzeczy do wypróbowania.

1. Usuwanie pliku .pid mniszka

Czy jest obecny plik blokady yum? Co się stanie, gdy usuniesz ten plik blokady? Myślę, że to może pozwolić na kontynuację.

rm /var/run/yum.pid

2. Wymuszenie CLOSE_WAITzamknięcia wszystkich zawieszonych połączeń TCP

A CLOSE_WAITopisano w następujący sposób:

CLOSE_WAIT Wskazuje, że serwer otrzymał pierwszy sygnał FIN od klienta i połączenie jest w trakcie zamykania

Zasadniczo oznacza to, że jest to stan, w którym gniazdo czeka na wykonanie przez aplikację close ()

Gniazdo może znajdować się w stanie CLOSE_WAIT przez czas nieokreślony, dopóki aplikacja go nie zamknie. Nieprawidłowe scenariusze przypominałyby wyciek skryptu pliku, serwer nie jest wykonywany close () na gnieździe, co prowadzi do gromadzenia się gniazd close_wait

UWAGA: Fragment strony internetowej technet .

Istnieją dwa narzędzia, których możesz użyć, aby to osiągnąć.

Narzędzia te działają poprzez symulację wymiany FIN-ACK-RST, która jest niezbędna do całkowitego zamknięcia połączenia TCP.

Killcx działa, tworząc fałszywy pakiet SYN z fałszywym SeqNum, fałszując adres IP / port zdalnego klienta i wysyłając go na serwer. Rozwiąże proces potomny, który przechwyci odpowiedź serwera, wyodrębni 2 magiczne wartości z pakietu ACK i użyje ich do wysłania sfałszowanego pakietu RST. Połączenie zostanie wówczas zamknięte.

UWAGA: Fragment strony internetowej Killcx .

Za pomocą noża

Przerywa określone połączenie między dwiema podanymi parami numerów IP / portu.

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

Korzystanie z Killcx

Zrywa połączenia ze zdalnym ip i portem.

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

Zasoby

— slm
źródło
Usunięcie pliku blokady nie przyniosło żadnego efektu.
— del
1
To jest na maszynie produkcyjnej i niestety te dwa narzędzia mają zależności, których nie mogę zainstalować. Próbowałem /etc/init.d/networking restartu i nic nie zrobiłem. Właściwie jestem teraz bardziej zainteresowany zrozumieniem, dlaczego tak się dzieje (ponieważ nie sądziłem, że przerywalne procesy uśpienia były w stanie zignorować SIGKILL), niż tym, jak mogę rozwiązać ten problem.
— del
Ponowne uruchomienie sieci miałoby ten sam efekt, więc blokowanie we / wy, jeśli tak naprawdę czeka proces, leży gdzie indziej.
— slm
1

Możesz spróbować zabić proces nadrzędny. Użyj ps, aby sprawdzić:

ps xjf -C yum

Następnie kill -9wszelkie procesy nadrzędne.

— terdon
źródło
Proces nadrzędny to init (5. kolumna w moich wynikach).
— del
1

Warto przyłączyć się do procesu za pomocą strace, aby sprawdzić, czy jest on naprawdę bezczynny lub utknął w operacji IO. Może może dostarczyć dalszych wskazówek w tej kwestii.

strace -pPID

Z tego, co przeczytałem, nie ma innego sposobu na zabicie tego procesu niż ponowne uruchomienie. Jeśli proces nie zużywa zauważalnego czasu procesora, jest mało prawdopodobne, aby wywarł jakikolwiek negatywny wpływ na serwer.

Dzięki za sugestię, ale proces nadrzędny to init (patrz 5. kolumna w moich wynikach).
— del
Jeśli chodzi o twoją poprawioną odpowiedź, strace dołącza się do procesu, ale niczego nie generuje.
— del
1

Czy to możliwe, że czeka na proces potomny? Uwielbiam, ps fauxbo powie ci, czy są procesy potomne, a jeśli tak, to być może będziesz musiał zabić.

— Stefan Seidel
źródło
Nie, ten proces nie ma żadnych procesów potomnych.
— del
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.