Неможливо вбити процес сну

13

Я, здається, не в змозі вбити -9 процес, який перебуває у стані перервного сну:

[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

Як це можливо? Чи є спосіб знищити процес без перезавантаження?

BOUNTY: Мені справді більше цікаво пояснення того, як можливо це відбуватися.

ОНОВЛЕННЯ: Це вихід lsof:

[root @ jupiter ~] # lsof -p 16790
ВИМОГА ПІДПРИЄМНИКА ПІДПРИЄМЦЯ FD ТИП ПРИЛАДУ ВИДАЛЕННЯ / ВИМК
yum 16790 корінь cwd DIR 1166,56842 4096 16886249 / home / del
yum 16790 корінь rtd DIR 253,0 4096 2 /
yum 16790 root txt REG 253,0 8304 336177337 / usr / bin / python
yum 16790 root mem REG REG 253,0 144776 346128569 /lib64/ld-2.5.so
yum 16790 root mem REG REG 253,0 1718232 346128573 /lib64/libc-2.5.so
yum 16790 root mem REG REG 253,0 23360 346128599 /lib64/libdl-2.5.so
yum 16790 root mem REG REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
yum 16790 root mem REG REG 253,0 615136 346128602 /lib64/libm-2.5.so
yum 16790 root mem REG 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 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 REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
yum 16790 root mem REG REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
yum 16790 root mem REG REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
yum 16790 root mem REG REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
yum 16790 root mem REG REG 253,0 17992 336187563 /usr/lib64/libplc4.so
yum 16790 root mem REG REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
yum 16790 root mem REG REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
yum 16790 root mem REG REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
yum 16790 root mem REG REG 253,0 1297136 336176959 /usr/lib64/libxml2.so.2.6.26
yum 16790 root mem REG REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
yum 16790 root mem REG REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
yum 16790 root mem REG REG 253,0 18152 346128670 /lib64/libutil-2.5.so
yum 16790 root mem REG REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
yum 16790 root mem REG REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
yum 16790 root mem REG REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
yum 16790 root mem REG REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
yum 16790 root mem REG REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
yum 16790 root mem REG REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
yum 16790 root mem REG 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 REG 253,0 247496 346128741 /lib64/libsepol.so.1
yum 16790 root mem REG REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
yum 16790 root mem REG REG 253,0 312336 336178453 /usr/lib64/libfreebl3.so
yum 16790 root mem REG 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 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 REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
yum 16790 root mem REG REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
yum 16790 root mem REG 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 REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
yum 16790 root mem REG REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
yum 16790 root mem REG 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 REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
yum 16790 root mem REG REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
yum 16790 root mem REG 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 REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
yum 16790 root mem REG REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
yum 16790 root mem REG 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 REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
yum 16790 root mem REG REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
yum 16790 root mem REG REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
yum 16790 root mem REG REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
yum 16790 root mem REG 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 REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
yum 16790 root mem REG 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 REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
yum 16790 root mem REG REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
yum 16790 root mem REG REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
yum 16790 root mem REG REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
yum 16790 root mem REG 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 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 REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
yum 16790 root mem REG REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
yum 16790 root mem REG 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 REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
yum 16790 root mem REG REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
yum 16790 root mem REG REG 253,0 24576 236520047 /var/lib/rpm/__db.001
yum 16790 root mem REG 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 REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
yum 16790 root mem REG 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 корінь 0u CHR 136,8 0t0 10 / dev / pts / 8 (видалено)
yum 16790 корінь 1u CHR 136,8 0t0 10 / dev / pts / 8 (видалено)
yum 16790 корінь 2u CHR 136,8 0t0 10 / dev / pts / 8 (видалено)
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 (видалено)
yum 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (видалено)
yum 16790 root 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (видалено)
yum 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (видалено)
yum 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (видалено)
yum 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (видалено)
yum 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / пакети
yum 16790 root 13r REG 253,0 45056 236519438 / var / lib / rpm / Назва
yum 16790 корінь 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (Встановлено)
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 / пакети
yum 16790 root 17r REG 253,0 45056 236519438 / var / lib / rpm / Назва
yum 16790 root 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
ням 16790 корінь 20р FIFO 0,6 0t0 4676024 труба
yum 16790 корінь 24w FIFO 0,6 0t0 4676024 труба

— дель
джерело

Вбийте інші процеси, які маніпулюють тим самим замком, і це, ймовірно, уджам.

— Девід Шварц

@David - я не можу вбити жоден з процесів yum у списку процесів вище; всі вони мають однакову проблему.

— дель

Я видалив зайві рядки, оскільки вони не додавали більше інформації, і вони ускладнювали читання вашої публікації.

— тердон

@slm - lsof показує TCP-сокети riksun.riken.go.jp:80 (Встановлено) та freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Я здогадуюсь, що це могло бути?

— дель

@slm - Перегляньте моє оновлене запитання.

— дель

18

Процес у стані S або D зазвичай відбувається у системному виклику блокування, такому як читання або запис у файл або мережу, очікування завершення викликаної програми або очікування семафорів або інших примітивів синхронізації. Він перейде у стан сну під час очікування.

Ви не можете "розбудити його" - він продовжиться лише тоді, коли дані / ресурс, який він чекає, стануть доступними. Це все нормально і очікувано, і лише проблема при спробі його вбити.

Ви можете спробувати і використати, strace -p pidщоб дізнатися, який системний виклик зараз відбувається для процесу pid.

З Вікіпедії :

Стан безперебійного сну - це стан сну, який не обробляє сигнал відразу. Він прокинеться лише в результаті отримання ресурсу, що чекає, або після того, як відбудеться тайм-аут під час цього очікування (якщо вказано, коли він лягає спати). Він здебільшого використовується драйверами пристроїв, які чекають дискового або мережевого вводу-виводу (введення / виведення). Коли процес спить безперебійно, сигнали, накопичені під час сну, будуть помічені, коли процес повертається із системного виклику чи пастки.

Процес, заблокований у системному дзвінку, знаходиться у режимі безперебійного сну, який, як видно з його назви, справді безперебійний навіть коренем.

Зазвичай процеси не можуть блокувати SIGKILL. Але код ядра може і процеси виконувати код ядра під час виклику системних викликів, під час якого код ядра блокує всі сигнали. Отже, якщо системний виклик блокується на невизначений термін, фактично неможливо вбити спосіб. SIGKILL набере чинності лише тоді, коли процес завершить системний виклик.

— harrymc
джерело

2

Я думав, що лише безперебійний процес сну зміг блокувати SIGKILL. Чи здатні також процеси переривання сну? Якщо так, то в чому різниця між ними?

— дель

1

І S, і D фактично є безперебійними, просто тому, що вони занадто складні для програмування в ядрі і тому, що в минулому вони повинні були мати дуже коротку тривалість. Незважаючи на те, що ядро еволюціонувало до включення NFS та інших випадків, які можуть зайняти набагато більше часу, очікування блокування ядра, на жаль, ніколи не скасовували.

— harrymc

3

Цікаво. Чи є у вас якісь посилання на це? Все, що я можу знайти в Google, схоже, говорить про те, що процеси переривання не повинні ігнорувати SIGKILL.

— дель

1

Це, здається, суперечить усьому, що я читав про переривчастий сон, і я трохи скептичний, що натрапив на якусь недокументовану поведінку. наприклад, Перевірте наступні 2 посилання. Я щось нерозумію? (1) "У режимі переривання сну процес може бути пробуджений для обробки сигналів". (2) "Якщо сигнал генерується для процесу в такому стані, то операція переривається і процес пробуджується подачею сигналу."

— дель

1

Виклик системи є переривним або не залежить лише від того, як він був запрограмований. Коли один знаходиться в ядрі, то все йде.

— harrymc

10

Фон на процес сну

Ви можете поглянути на цю публікацію про Unix & Linux.

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

Конкретно ця відповідь /unix//a/5648/7453 .

Витяг з цієї посади

kill -9 (SIGKILL) завжди працює, якщо у вас є дозвіл на вбивство процесу. По суті, або процес повинен бути запущений вами, і не бути налаштованим або налаштованим, або ви повинні мати root. Є один виняток: навіть root не може надсилати фатальний сигнал PID 1 (процес init).

Однак знищення -9 не гарантовано працює негайно. Усі сигнали, включаючи SIGKILL, доставляються асинхронно: ядро може зайняти час для їх доставки. Зазвичай подача сигналу займає максимум кілька мікросекунд, саме час, який потрібен цілі, щоб отримати відрізок часу. Однак якщо ціль заблокувала сигнал, сигнал буде в черзі, поки ціль не розблокує його.

Зазвичай процеси не можуть блокувати SIGKILL. Але код ядра може і процеси виконувати код ядра під час виклику системних викликів. Код ядра блокує всі сигнали, коли переривання системного виклику призводить до погано сформованої структури даних десь у ядрі, або, загалом, до порушення інваріанта ядра. Отже, якщо (через помилку чи неправильного проекту) системний виклик блокується на невизначений термін, фактично не може бути способу вбити процес. (Але процес буде вбито, якщо він коли-небудь завершить системний виклик.)

...

...

Я настійно пропоную прочитати решту відповіді!

Вбивство процесу, який блокується ресурсом (файлом або мережею)

Ось дві речі, які слід спробувати.

1. Видалення .um файлу .um

Чи присутній файл yum lock? Що станеться, коли ви видалите цей файл блокування? Я думаю, що це може дозволити йому продовжуватися.

rm /var/run/yum.pid

2. Примушуючи будь-які підвісні `CLOSE_WAIT`з'єднання TCP закриті

А CLOSE_WAITописується так:

CLOSE_WAIT Позначає, що сервер отримав перший клієнтський сигнал від клієнта, і з'єднання перебуває в процесі закриття

Отже, це по суті означає, що його стан, коли сокет чекає, коли програма виконає close ()

Сокет може перебувати у стані CLOSE_WAIT нескінченно, доки програма не закриє його. Несправні сценарії, як-от витоку fileescriptor, сервер не виконується close () на сокеті, що веде до накопичення сокет close_wait

ПРИМІТКА: Витяг з веб-сайту technet .

Є два інструменти, які ви можете спробувати використати для цього.

Ці інструменти працюють, імітуючи обмін FIN-ACK-RST , необхідний для повного закриття з'єднання TCP.

Killcx працює, створюючи підроблений пакет SYN з фальшивим SeqNum, підробляючи IP / порт віддаленого клієнта і відсилаючи його на сервер. Він розщепить дочірній процес, який буде захоплювати відповідь сервера, витягувати 2 магічні значення з пакета ACK і використовувати їх для надсилання підробленого пакету RST. Потім з'єднання буде закрито.

ПРИМІТКА: Витяг із веб-сайту Killcx .

Використання різця

Вирізає конкретне з'єднання між двома заданими парами ip / port.

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

Використання Killcx

Перериває з'єднання з віддаленим ip & портом.

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

Ресурси

сервер за замовчуванням - Як примусово закрити розетку вчасно зачекати

— слм
джерело

Видалення файлу блокування не мало ефекту.

— дель

1

Це на виробничій машині, і, на жаль, ці два інструменти мають залежності, які я не можу встановити. Я спробував /etc/init.d/networking перезапустити, і це нічого не зробило. Насправді мені зараз більше цікаво зрозуміти, чому це може статися (оскільки я не думав, що переривчасті процеси сну не змогли ігнорувати SIGKILL), а не як я можу вирішити цю проблему.

— дель

Перезапуск мережі матиме такий же ефект, тому блокування вводу-виводу, якщо це насправді те, на що очікує процес, лежить в іншому місці.

— slm

1

Ви можете спробувати вбити батьківський процес. Використовуйте ps для перевірки:

ps xjf -C yum

Тоді kill -9будь-який батьківський обробляє.

— тердон
джерело

Батьківський процес - це init (5-й стовпець у моєму виході).

— дель

1

Можливо, варто приєднатись до процесу з розтяжкою, щоб перевірити, чи він справді непрацюючий або застряг в операції вводу-виводу. Можливо, це дасть додаткові підказки до цього питання.

strace -pPID

З того, що я прочитав, немає іншого способу вбити цей процес, крім перезавантаження. Якщо процес не вимагає помітного процесорного часу, це навряд чи створить негативний вплив на сервер.

Дякую за пропозицію, але батьківський процес є init (див. 5-й стовпчик у моєму виході).

— дель

Перегляньте свою переглянуту відповідь, штрих додається до процесу, але нічого не виводить.

— дель

1

Чи може бути, що він чекає дитячого процесу? Мені подобається, ps fauxтому що вона підкаже, чи є дочірні процеси чи ні, які, можливо, потрібно буде вбити.

— Стефан Зайдель
джерело

Ні, цей процес не має жодних дочірніх процесів.

— дель

Неможливо вбити процес сну

Фон на процес сну

Вбивство процесу, який блокується ресурсом (файлом або мережею)

1. Видалення .um файлу .um

2. Примушуючи будь-які підвісні CLOSE_WAITз'єднання TCP закриті

Використання різця

Використання Killcx

Ресурси

2. Примушуючи будь-які підвісні `CLOSE_WAIT`з'єднання TCP закриті