Все еще жив, еще жив после убийства -9 / SIGKILL

Процесс apache2 застрял на моем сервере и вызвал проблемы с другими службами. (оригинальная проблема: kerneloops после отсоединения устройства USB)

root@server:~# ps aux | grep apache2 | grep -v grep www-data 12917 0.0 0.1 412148 16156 ? D Jun27 0:00 /usr/sbin/apache2 -k start 

Естественно, я kill его. он все еще жив. поэтому я kill -9 его. Он все еще «жив».

Теперь в этом вопросе возникает serverfault / unix & linux-worthy: есть ли способ вернуть порт 443, не делая очевидной вещи: перезагрузка? Установлен Iptables.

Обновление: я не мог решить проблему с перезагрузкой. Общий подход (использовать lsof или /proc/$PID/fd чтобы узнать, который и избавиться от этого диска), как описано здесь и в «дубликате», вполне мог бы работать, если бы не дополнительные (возможно) аппаратные дефекты.

  • Как найти источник нереста?
  • Как сделать сценарий инициализации «ОК», только когда все подпроцессы остановлены?
  • Остановить задачу на основе вывода
  • Разница между «убить | pgrep dnsspoof "и" kill `pgrep dnsspoof"
  • Не удается завершить или приостановить фоновое задание
  • Остановка заданий с помощью PID?
  • pkill не может убивать процессы с родительским идентификатором процесса 1
  • Попытка написать сценарий для запуска процессов, основанных на тонкости
  • One Solution collect form web for “Все еще жив, еще жив после убийства -9 / SIGKILL”

    Состояние «D» неудобно. Процесс может быть убит только тогда, когда он находится в пользовательском пространстве (его код делает все, что делает). Когда вызывается системный вызов (чаще всего проблема – операции ввода-вывода), ядро ​​берет на себя, пока не вернется системный вызов. В режиме ядра процесс не может быть убит. Прерывание кода ядра опасно для всей системы, и, кроме того, это также философский вопрос, если процесс в режиме ядра должен слушать сигналы, учитывая, что он не контролируется.

    Таким образом, единственным выходом из режима ядра является тайм-аут / прерывание от самого кода. Операции ввода-вывода на сетевых дисках обычно чрезмерно защищены и не хотят отказываться от потери данных. Если ваш сетевой диск недоступен (или любой другой ввод-вывод, доступ к устройству / … сбой), ваш процесс может ждать почти бесконечно в состоянии «disk zombie».

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

    Linux и Unix - лучшая ОС в мире.