Không thể giết quá trình ngủ


13

Tôi dường như không thể giết -9 một quá trình ở trạng thái ngủ gián đoạn (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

Sao có thể như thế được? Có cách nào để giết quá trình mà không cần khởi động lại?

BOUNTY: Tôi thực sự quan tâm nhiều hơn đến một lời giải thích về việc điều này có thể xảy ra như thế nào.

CẬP NHẬT: Đây là đầu ra của lsof:

[root @ jupiter ~] # lsof -p 16790
NGƯỜI DÙNG ĐIỀU KHIỂN NGƯỜI DÙNG FD LOẠI THIẾT BỊ THIẾT BỊ / TẮT NODE
yum 16790 root cwd TRỰC TIẾP 1166,56842 4096 16886249 / nhà / del
yum 16790 root rtd TRỰC TIẾP 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
yum 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/libapiat.so.0.5.0
yum 16790 root mem REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
yum 16790 root mem ĐĂNG KÝ
yum 16790 root mem REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
yum 16790 root mem ĐĂNG KÝ
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
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
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
yum 16790 root mem REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_rand Itemule.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 / lib4 / python2.4 / lib-dynload / bz2.so
yum 16790 root mem
yum 16790 root mem ĐĂNG KÝ
yum 16790 root mem
yum 16790 root mem
yum 16790 root mem
yum 16790 root mem REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
yum 16790 root mem ĐĂNG KÝ
yum 16790 root mem ĐĂNG KÝ
yum 16790 root mem ĐĂNG KÝ
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 336265456 /usr/lib64/gconv/gconv-modules.cache
yum 16790 root mem ĐĂNG KÝ
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/unicodingata.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
yum 16790 root 0u CHR 136,8 0t0 10 / dev / pts / 8 (đã xóa)
yum 16790 root 1u CHR 136,8 0t0 10 / dev / pts / 8 (đã xóa)
yum 16790 root 2u CHR 136,8 0t0 10 / dev / pts / 8 (đã xóa)
yum 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 ổ cắm
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 (đã xóa)
yum 16790 root 7u ĐĂNG KÝ
yum 16790 root 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (đã xóa)
yum 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (đã xóa)
yum 16790 root 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (đã xóa)
yum 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (đã xóa)
yum 16790 root 12r REG 253,0 65204224 236519434 / var / lib / vòng / phút
yum 16790 root 13r REG 253,0 45056 236519438 / var / lib / vòng / phút
yum 16790 root 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (THÀNH LẬP)
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 / vòng / gói
yum 16790 root 17r REG 253,0 45056 236519438 / var / lib / vòng / phút
yum 16790 root 18r REG 253,0 12288 236519440 / var / lib / vòng / Pubkey
yum 16790 root 20r FIFO 0,6 0t0 4676024 ống
yum 16790 root 24w FIFO 0,6 0t0 4676024 ống

Giết các tiến trình khác thao túng cùng một khóa và nó có thể sẽ không hoạt động.
David Schwartz

@David - Tôi không thể giết bất kỳ quy trình yum nào trong danh sách quy trình ở trên; tất cả họ đều có cùng một vấn đề.
del

Tôi đã xóa các dòng bổ sung vì chúng không thêm bất kỳ thông tin nào và chúng làm cho việc đọc bài viết của bạn trở nên khó khăn hơn.
terdon

@slm - lsof hiển thị các socket TCP cho riksun.riken.go.jp:80 (THÀNH LẬP) và Freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Tôi đoán đó có thể là nó?
del

@slm - Xin vui lòng xem câu hỏi cập nhật của tôi.
del

Câu trả lời:


18

Một quá trình ở trạng thái S hoặc D thường trong một cuộc gọi hệ thống chặn, chẳng hạn như đọc hoặc ghi vào tệp hoặc mạng, chờ chương trình được gọi kết thúc hoặc trong khi chờ đợi trên semaphores hoặc các nguyên hàm đồng bộ hóa khác. Nó sẽ đi vào trạng thái ngủ trong khi chờ đợi.

Bạn không thể "đánh thức nó" - nó sẽ chỉ tiếp tục khi dữ liệu / tài nguyên mà nó đang chờ có sẵn. Đây là tất cả bình thường và dự kiến, và chỉ là một vấn đề khi cố gắng để giết nó.

Bạn có thể thử và sử dụng strace -p pidđể tìm ra cuộc gọi hệ thống nào đang diễn ra cho quá trình xử lý.

Từ wikipedia :

Trạng thái ngủ không bị gián đoạn là trạng thái ngủ sẽ không xử lý tín hiệu ngay lập tức. Nó sẽ chỉ thức dậy do tài nguyên chờ đợi trở nên khả dụng hoặc sau khi hết thời gian chờ trong thời gian chờ đó (nếu được chỉ định khi đưa vào chế độ ngủ). Nó chủ yếu được sử dụng bởi trình điều khiển thiết bị đang chờ đĩa IO hoặc mạng (đầu vào / đầu ra). Khi quá trình đang ngủ liên tục, các tín hiệu tích lũy trong khi ngủ sẽ được chú ý khi quá trình quay trở lại từ cuộc gọi hệ thống hoặc bẫy.

Một quá trình bị chặn trong một cuộc gọi hệ thống là trong giấc ngủ không bị gián đoạn, như tên gọi của nó, thực sự không thể bị gián đoạn ngay cả bằng root.

Thông thường, các quy trình không thể chặn SIGKILL. Nhưng mã kernel có thể và các tiến trình thực thi mã kernel khi chúng gọi các cuộc gọi hệ thống, trong đó mã Kernel chặn tất cả các tín hiệu. Vì vậy, nếu một hệ thống gọi các khối vô thời hạn, có hiệu quả có thể không có cách nào để giết quá trình. SIGKILL sẽ chỉ có hiệu lực bất cứ khi nào quá trình hoàn thành cuộc gọi hệ thống.


2
Tôi nghĩ rằng chỉ có các quá trình ngủ không bị gián đoạn mới có thể chặn SIGKILL. Là quá trình ngủ gián đoạn có thể là tốt? Nếu vậy, sự khác biệt giữa chúng là gì?
del

1
Cả hai trạng thái S và D đều có hiệu lực không bị gián đoạn, đơn giản là vì quá phức tạp để lập trình trong kernel và bởi vì trong quá khứ, chúng được cho là chỉ có thời lượng rất ngắn. Mặc dù kernel đã phát triển để bao gồm NFS và các trường hợp khác có thể mất nhiều thời gian hơn, nhưng rất tiếc, việc chờ đợi chặn kernel không bao giờ bị xóa bỏ.
harrymc

3
Hấp dẫn. Bạn có bất kỳ tài liệu tham khảo cho điều này? Mọi thứ tôi có thể tìm thấy với Google dường như đều nói rằng các quy trình gián đoạn không thể bỏ qua SIGKILL.
del

1
Nó dường như mâu thuẫn với tất cả mọi thứ tôi đã đọc về giấc ngủ gián đoạn, và tôi hơi nghi ngờ rằng tôi đã vấp phải một số hành vi không có giấy tờ. ví dụ: Kiểm tra 2 liên kết sau. Tôi có hiểu lầm gì không? (1) "Trong một giấc ngủ gián đoạn, quá trình có thể được đánh thức để xử lý tín hiệu." (2) "Nếu tín hiệu được tạo cho một quá trình ở trạng thái này, thì hoạt động bị gián đoạn và quá trình này được đánh thức bằng cách phát tín hiệu."
del

1
Một cuộc gọi hệ thống có thể bị gián đoạn hay không chỉ phụ thuộc vào cách nó được lập trình. Một khi một trong các kernel thì mọi thứ sẽ đi.
harrymc

10

Bối cảnh về quá trình ngủ

Bạn có thể muốn xem qua bài viết Unix & Linux này.

Cụ thể câu trả lời này, /unix//a/5648/7453 .

Trích từ bài viết đó

kill -9 (SIGKILL) luôn hoạt động, miễn là bạn được phép giết tiến trình. Về cơ bản, quá trình phải được bắt đầu bởi bạn và không được setuid hoặc setgid, hoặc bạn phải root. Có một ngoại lệ: ngay cả root cũng không thể gửi tín hiệu gây tử vong cho PID 1 (quá trình init).

Tuy nhiên kill -9 không được đảm bảo để hoạt động ngay lập tức. Tất cả các tín hiệu, bao gồm SIGKILL, được phân phối không đồng bộ: hạt nhân có thể mất thời gian để phân phối chúng. Thông thường, việc cung cấp tín hiệu mất tối đa vài micro giây, chỉ cần thời gian để mục tiêu có được một lát cắt thời gian. Tuy nhiên, nếu mục tiêu đã chặn tín hiệu, tín hiệu sẽ được xếp hàng cho đến khi mục tiêu mở khóa.

Thông thường, các quy trình không thể chặn SIGKILL. Nhưng mã kernel có thể và các tiến trình thực thi mã kernel khi chúng gọi các cuộc gọi hệ thống. Mã hạt nhân chặn tất cả các tín hiệu khi làm gián đoạn cuộc gọi hệ thống sẽ dẫn đến cấu trúc dữ liệu được hình thành xấu ở đâu đó trong kernel hoặc nói chung là trong một số bất biến kernel bị vi phạm. Vì vậy, nếu (do lỗi hoặc xác định sai) một khối gọi hệ thống vô thời hạn, thực sự có thể không có cách nào để giết quá trình. (Nhưng quá trình sẽ bị hủy nếu nó hoàn thành lệnh gọi hệ thống.)

...

...

Tôi rất khuyên bạn nên đọc phần còn lại của câu trả lời!

Giết quá trình bị chặn bởi tài nguyên (tệp hoặc mạng)

Dưới đây là 2 điều cần thử.

1. Xóa tệp .pid của yum

Có một tập tin khóa yum hiện tại? Điều gì xảy ra khi bạn loại bỏ tập tin khóa đó? Tôi nghĩ rằng có thể cho phép nó tiến hành.

rm /var/run/yum.pid

2. Buộc đóng mọi CLOSE_WAITkết nối TCP bị đóng

A CLOSE_WAITđược mô tả như sau:

CLOSE_WAIT Cho biết rằng máy chủ đã nhận được tín hiệu FIN đầu tiên từ máy khách và kết nối đang trong quá trình đóng

Vì vậy, điều này về cơ bản có nghĩa là trạng thái của nó là socket đang chờ ứng dụng thực thi close ()

Một ổ cắm có thể ở trạng thái CLOSE_WAIT vô thời hạn cho đến khi ứng dụng đóng nó. Các tình huống bị lỗi sẽ giống như rò rỉ filedescriptor, máy chủ không được thực thi close () trên socket dẫn đến chồng các socket close_wait

LƯU Ý: Trích từ trang web của Technet .

Có 2 công cụ bạn có thể thử sử dụng để thực hiện điều này.

Các công cụ này hoạt động bằng cách mô phỏng trao đổi FIN-ACK-RST cần thiết để kết nối TCP được đóng hoàn toàn.

Killcx hoạt động bằng cách tạo một gói SYN giả với SeqNum không có thật, giả mạo IP / cổng máy khách từ xa và gửi nó đến máy chủ. Nó sẽ rẽ nhánh một tiến trình con sẽ nắm bắt phản hồi của máy chủ, trích xuất 2 giá trị ma thuật từ gói ACK và sử dụng chúng để gửi gói RST giả mạo. Kết nối sau đó sẽ được đóng lại.

LƯU Ý: Trích từ trang web Killcx .

Sử dụng máy cắt

Cắt kết nối cụ thể giữa hai cặp số ip / cổng đã cho.

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

Sử dụng Killcx

Cắt kết nối đến ip & port từ xa.

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

Tài nguyên


Loại bỏ các tập tin khóa không có hiệu lực.
del

1
Đây là trên một máy sản xuất, và thật không may, hai công cụ này có các phụ thuộc mà tôi không thể cài đặt. Tôi đã thử /etc/init.d/networking restart và nó không làm gì cả. Trên thực tế, bây giờ tôi quan tâm nhiều hơn đến việc hiểu tại sao điều này có thể xảy ra (vì tôi không nghĩ rằng các quá trình ngủ gián đoạn có thể bỏ qua SIGKILL) hơn là cách tôi có thể khắc phục vấn đề này.
del

Khởi động lại mạng sẽ có tác dụng tương tự, do đó, việc chặn I / O, nếu thực tế đó là quá trình đang chờ đợi, nằm ở đâu đó.
slm

1

Bạn có thể thử giết quá trình cha mẹ. Sử dụng ps để kiểm tra:

ps xjf -C yum

Sau đó, kill -9bất kỳ quá trình cha mẹ.


Quá trình cha là init (cột thứ 5 trong đầu ra của tôi).
del

1

Có thể đáng để gắn vào quy trình với bước tiến để xem liệu nó có thực sự nhàn rỗi hoặc bị mắc kẹt trên một hoạt động IO. Có thể cung cấp thêm manh mối cho vấn đề có lẽ.

bước đi -pPID

Từ những gì tôi đã đọc, không có cách nào để giết quá trình này ngoài việc khởi động lại. Nếu quá trình không tiêu tốn bất kỳ thời gian cpu đáng chú ý nào, không có khả năng tạo ra bất kỳ tác động tiêu cực nào đến máy chủ.


Cảm ơn đề xuất, nhưng quá trình cha là init (xem cột thứ 5 trong đầu ra của tôi).
del

Trả lời sửa đổi của bạn, strace gắn liền với quá trình nhưng không xuất ra bất cứ điều gì.
del

1

Có thể là nó đang chờ một quá trình con? Tôi yêu ps fauxbởi vì nó sẽ cho bạn biết liệu có quá trình con hay không, và nếu, bạn có thể cần phải giết.


Không, quá trình này không có bất kỳ quy trình con nào.
del
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.