Как убить зависший сервис на Windows 2008R2

8

У меня есть сервер Windows 2008R2 под управлением NSClient ++. По какой-то причине служба перевернулась и перестала отвечать на опрос Nagios.

Когда я попытался перезапустить службу, диспетчеру службы потребовалось много времени, чтобы попытаться убить службу, а затем, в конечном итоге, я получил сообщение «служба заняла слишком много времени, чтобы ответить». Но ... он также запускает новый экземпляр службы.

Если я смотрю в диспетчере задач или tasklistтеперь я вижу два экземпляра nsclient++.exeзапуска.

Я пытался убить оба из них, используя:

  • щелкните правой кнопкой мыши и «Завершить процесс» в диспетчере задач - делает вид, что убивает процесс, и не сообщает об ошибках (например, «Доступ запрещен»), но процесс все еще там.

  • taskkill /PID <proc id> /F- сообщает, SUCCESS: The process with PID 6672 has been terminated.но процесс все еще выполняется.

  • скачал SysInternals PsTools и запустил pskill <PID>- отчеты Process <PID> killed- но процесс все еще там.

  • выполнить, at hh:mm pskill <PID>чтобы pskillсделать это в качестве SYSTEMучетной записи ... и вы догадались, что процесс все еще выполняется.

Все вышеперечисленное было запущено в командной строке администратора.

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

Сервер не находится под давлением ресурсов (память, процессор, диск и т. Д.), И все, что на нем работает, работает просто отлично.

Быстрый просмотр вкладки потоков в SysInternals Process Explorer показывает, что все эти nsclient++.exeэкземпляры застряли при выгрузке:

введите описание изображения здесь

Кроме того, я также попытался убить все соединения TCP для этих процессов зомби (?) (С TCPView) в надежде, что я смогу запустить новый экземпляр, и он сможет захватить порт 5666. Затем мы сможем перезагрузить сервер когда все тише, но, увы, это не сработало.

Кев
источник
3
Если процесс не завершится с помощью диспетчера задач, он фактически застрянет в подпрограмме ядра ... Так что у Windows проблемы. У вас установлены "интересные" драйвера?
Крис С
Там нет ничего действительно экзотического бега с точки зрения водителя. Это XenServer VM, так же как и обычные драйверы Xen, с которыми у нас обычно нет проблем. Мы также запускаем R1 CDP Enterprise, и это, кажется, работает в рамках наших нормальных рабочих параметров. Я добавил скриншот, показывающий вкладку Темы из procxp.exe.
Кев
Если вы нажмете Stack, как выглядит стек для застрявших потоков?
HeatfanJohn
@HeatfanJohn - Я тоже об этом думал, но получаю сообщение об ошибке «Ошибка доступа к ветке» .
Кев
Я предполагаю, что это связано с комментарием @ChrisS о том, что он застрял в подпрограмме ядра.
HeatfanJohn

Ответы:

3

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

Возможно, стоит попробовать отладку ядра ( этот инструмент работает на 2008 R2 ?) В надежде сузить конкретную причину или конфликт, но ваши варианты решения проблемы либо живут с ней, либо перезагружают сервер, чтобы устранить ее.

Есть ли причина, по которой ты не думал жить с этим? Если это всего лишь процесс зомби, и он ни на что не влияет, я думаю, вы могли бы отложить перезагрузку до периода обслуживания или более подходящего времени. Как правило, мой подход, когда процесс зомби или зависания ни на что не мешает - позаботьтесь об этом во время следующего цикла исправлений или запланированного периода обслуживания.

HopelessN00b
источник
К сожалению, слишком поздно, чтобы исследовать эти процессы в WinDbg, ребята из инфраструктуры перезагрузили сервер. Но удобно знать в следующий раз.
Кев
Другая проблема заключалась в том, что мы не могли с этим смириться. Служба - NSClient ++, которую мы используем вместе с nagios. Я даже не смог получить свежий exe-сервис для запуска и ответа на запросы опроса, я думаю, потому что эти зомбированные процессы все еще зависали на порту 5666, который он прослушивает (конечно, можно было увидеть, что один из них все еще держится за порт в TCPView, и я не мог закрыть это).
Кев
Ну, это, безусловно, очень веская причина не жить с этим.
HopelessN00b
Если это случится снова, не забудьте еще одного ребенка Марка Руссиновича - Process Monitor. Укажите procmon на процесс, чтобы увидеть, что он делает. Прекрасный инструмент.
Саймон Кэтлин
@SimonCatlin - да, я тоже так делал, но на меня ничего не вышло.
Кев