Не может убить процесс сна


13

Кажется, я не могу убить -9 процесс, который находится в состоянии прерывистого сна (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

Как это возможно? Есть ли способ убить процесс без перезагрузки?

BOUNTY: Меня действительно больше интересует объяснение того, как это возможно.

ОБНОВЛЕНИЕ: Это вывод lsof:

[root @ jupiter ~] # lsof -p 16790
КОМАНДА PID ПОЛЬЗОВАТЕЛЬ FD ТИП РАЗМЕР УСТРОЙСТВА / ВЫКЛЮЧЕНО NODE NAME
ням 16790 root cwd DIR 1166,56842 4096 16886249 / home / del
ням 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
ням 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-archive
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
ням 16790 корень 0u CHR 136,8 0t0 10 / dev / pts / 8 (удалено)
ням 16790 корень 1u CHR 136,8 0t0 10 / dev / pts / 8 (удалено)
ням 16790 root 2u CHR 136,8 0t0 10 / dev / pts / 8 (удалено)
yum 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 сокет
yum 16790 root 4w REG 253,0 0 236522326 /var/log/yum.log
ням 16790 root 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
ням 16790 root 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (удалено)
ням 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 (удалено)
ням 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (удалено)
ням 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (удалено)
ням 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / пакеты
yum 16790 root 13r REG 253,0 45056 236519438 / var / lib / rpm / Name
yum 16790 root 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)
ням 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / пакеты
ням 16790 root 17r REG 253,0 45056 236519438 / var / lib / rpm / Name
ням 16790 root 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
ням 16790 корень 20р FIFO 0,6 0t0 4676024 труба
ням 16790 root 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.

Из википедии :

Непрерывное состояние сна - это состояние сна, которое не будет обрабатывать сигнал сразу. Он будет активирован только в результате доступности ожидаемого ресурса или после истечения времени ожидания в течение этого ожидания (если указано при переводе в спящий режим). Он в основном используется драйверами устройств, ожидающими дискового или сетевого ввода-вывода (ввода / вывода). Когда процесс непрерывно спит, сигналы, накопленные во время сна, будут замечены, когда процесс вернется из системного вызова или прерывания.

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

Обычно процессы не могут блокировать SIGKILL. Но код ядра может, и процессы выполняют код ядра, когда они вызывают системные вызовы, во время которых код ядра блокирует все сигналы. Таким образом, если системный вызов блокируется на неопределенный срок, фактически не может быть способа убить процесс. SIGKILL вступит в силу только тогда, когда процесс завершит системный вызов.


2
Я думал, что только непрерывный процесс сна может блокировать SIGKILL. Могут ли прерваться процессы сна? Если так, то в чем разница между ними?
дель

1
Как S, так и D состояния в действительности бесперебойны просто потому, что слишком сложны для программирования в ядре, и потому что в прошлом они должны были быть очень короткими. Хотя ядро ​​эволюционировало для включения NFS и других случаев, которые могут занять гораздо больше времени, ожидания блокировки ядра, к сожалению, никогда не отменялись.
harrymc

3
Интересный. У вас есть ссылки на это? Все, что я могу найти в Google, говорит о том, что прерываемые процессы не должны игнорировать SIGKILL.
Дель

1
Кажется, что это противоречит всему, что я читал о прерывистых снах, и я немного скептически отношусь к тому, что наткнулся на какое-то недокументированное поведение. например, проверьте следующие 2 ссылки. Я что-то неправильно понимаю? (1) «Во время прерывистого сна процесс может быть активирован для обработки сигналов». (2) «Если сигнал генерируется для процесса в этом состоянии, то операция прерывается и процесс активируется доставкой сигнала».
дель

1
Системный вызов прерывается или не зависит только от того, как он был запрограммирован. Как только кто-то оказывается внутри ядра, тогда все идет.
harrymc

10

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

Возможно, вы захотите взглянуть на этот пост Unix & Linux.

Конкретно этот ответ, /unix//a/5648/7453 .

Выдержка из этого поста

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

Однако kill -9 не гарантирует немедленной работы. Все сигналы, включая SIGKILL, доставляются асинхронно: ядру может потребоваться время для их доставки. Обычно доставка сигнала занимает не более нескольких микросекунд, то есть времени, которое требуется для цели, чтобы получить интервал времени. Однако, если цель заблокировала сигнал, сигнал будет поставлен в очередь, пока цель не разблокирует его.

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

...

...

Я настоятельно рекомендую прочитать остальную часть этого ответа!

Убить процесс, заблокированный ресурсом (файл или сеть)

Вот 2 вещи, чтобы попробовать.

1. Удаление .pid файла yum

Есть ли файл блокировки yum? Что происходит, когда вы удаляете этот файл блокировки? Я думаю, что это могло бы позволить этому продолжаться.

rm /var/run/yum.pid

2. Принудительное CLOSE_WAITзакрытие любых зависших TCP-соединений

А CLOSE_WAITописывается следующим образом:

CLOSE_WAIT Указывает, что сервер получил первый сигнал FIN от клиента и соединение находится в процессе закрытия

Таким образом, это по существу означает, что его состояние является состоянием, когда сокет ожидает выполнения приложения close ()

Сокет может находиться в состоянии CLOSE_WAIT неопределенно долго, пока приложение не закроет его. Неисправные сценарии будут похожи на утечку файлового дескриптора, когда сервер не будет выполняться close () в сокете, что приведет к скоплению сокетов close_wait

ПРИМЕЧАНИЕ: выдержка из сайта Technet .

Есть 2 инструмента, которые вы можете попробовать использовать для достижения этой цели.

Эти инструменты работают путем имитации обмена 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 restart, и он ничего не сделал. На самом деле, теперь меня больше интересует понимание того, почему это может произойти (поскольку я не думал, что прерываемые процессы сна могли игнорировать SIGKILL), а не то, как я могу решить эту проблему.
Дель

Перезапуск сети будет иметь тот же эффект, поэтому блокировка ввода-вывода, если это фактически то, чего ожидает процесс, находится в другом месте.
SLM

1

Вы можете попытаться убить родительский процесс. Используйте PS, чтобы проверить:

ps xjf -C yum

Тогда kill -9любые родительские процессы.


Родительским процессом является init (5-й столбец в моем выводе).
Дель

1

Возможно, стоит подключиться к процессу с помощью strace, чтобы увидеть, действительно ли он простаивает или зависает в операции ввода-вывода. Может дать дополнительные подсказки к проблеме, возможно.

strace -pPID

Из того, что я прочитал, нет способа убить этот процесс, кроме как перезагрузить. Если процесс не потребляет сколько-нибудь заметного времени процессора, он вряд ли окажет какое-либо негативное влияние на сервер.


Спасибо за предложение, но родительским процессом является init (см. 5-й столбец в моем выводе).
дель

Что касается вашего исправленного ответа, strace присоединяется к процессу, но ничего не выводит.
Дель

1

Может ли быть так, что он ждет дочернего процесса? Я люблю, ps fauxпотому что он скажет вам, есть ли дочерние процессы, и если, которые вам, возможно, придется убить.


Нет, этот процесс не имеет дочерних процессов.
дель
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.