"Вбити <PID>" насправді не вбиває процес, чому?

Я намагаюся вдосконалити свої навички командного рядка, і у мене виникла проблема, коли я не можу вбити процес. Я набираю, kill 2200де 2200 - мій PID, і процес не вбивається. Через кілька хвилин очікування все ще перебуває в topі ps aux. Я навіть намагався набрати це з судо - результатів не було.

Будь-які ідеї, чому це було б так?

EDIT

Я знайшов дивну залежність, де fgоновлює список процесів:

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

Процеси можуть ігнорувати деякі сигнали. Якщо ви надішлете SIGKILL, він не зможе проігнорувати його (і не застане його робити очищення). Спробуйте:

kill -9 {PID}

Дізнайтеся більше, прочитавши сторінку керівництва:

man kill

Якщо killвиклик без жодного параметра, він надсилає сигнал номер 15 ( SIGTERM). Цей сигнал процес може ігнорувати. Цей сигнал сповіщає процес очищення своїх речей, а потім належним чином закінчується сам. Це приємний спосіб.

Ви також можете "надіслати" сигнал номер 9 ( SIGKILL), який не може бути проігнорований процесом. Процес навіть не розпізнає його, оскільки ядро ​​закінчує процес, а не сам процес. Це злий шлях.

Один каже, що kill -9 <pid>завжди працює. Це невіра . Бувають ситуації, коли навіть kill -9процес не вбиває. Наприклад, коли процес має стан D(режим безперебійного сну). Процес переходить у цей стан щоразу, коли він чекає вводу / виводу (як правило, не дуже довго). Отже, якщо процес чекає вводу-виводу (наприклад, на жорсткому диску дефекту) і він не запрограмований належним чином (з таймаутом), ви просто не можете вбити процес . Неважливо, чим ти займаєшся. Ви просто можете спробувати зробити файл доступним, щоб процес тривав.

Незважаючи на те, що ім'я вбивства насправді не вбиває процеси, воно надсилає сигнали до нього. На чоловіковій сторінці:

kill - send a signal to a process

Сигнал по замовчуванням посланий kill [pid]є SIGTERM , який зазвичай , але не обов'язково просить припинити процес. Цілком можливо написати програму, яка відтворює радісну мелодію, коли ви надсилаєте на неї сигнал SIGTERM , але не рекомендується.

Ще один поширений сигнал - SIGHUP, який часто використовується для прохання програми перечитати свої конфігураційні файли.

Якщо ви дійсно хочете вбити програму, вам потрібно скористатися сигналом SIGKILLkill -9 [pid] .

Здається, що ви можете призупинити процес (можливо, натиснувши Ctrl-Z в терміналі). У цьому стані ваш процес не реагуватиме на SIGTERM, оскільки він заморожений. Запуск "fg" відтає процес, тому він може приймати сигнал і самозавершуватися. Це може пояснити, чому з'являється "fg" для оновлення списку процесів.

Зсередини C ++ я виконав:

kill(4024, SIGKILL);

І на терміналі linux (Ubuntu),

$ ps -ax | grep my_su

Вихід був:

4024 pts/1    Z+     0:00 [my_subscriber] <defunct>

Здається, він (4024) все ще вижив. Однак, як тільки я припинив батьківський процес, який назвав вищезазначене твердження "знищити", 4024 більше не з'являвся. Тепер я вважаю, що процес "неіснуючий" - це не що інше, як відображений рядок, і вирішив його ігнорувати. Я сподіваюся, що мій досвід може допомогти комусь там. Ура!

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

Примітка: як вже могли згадати інші, використання kill -9 {PID}не рекомендується, якщо це не зомбі-процес. як тільки процес отримує SIGKILL, негайно відключиться без очищення чи будь-яких інших належних процедур.

Це те, що я використовував для таблетки localhost, що працює на порт 80 (За кутовим кліпом) Отримати інформацію про додаток про порт 80

sudo lsof -i tcp:80

After That 
sudo kill -9 3348

де 3348pid запущеного процесу