Еще раз об упрямых системных службах: как их запустить и запустить

Несколько месяцев назад я написал статью о том, как взять под контроль упрямые системные службы. Эта статья в основном посвящена использованию PowerShell для принудительного запуска службы после того, как служба не запускается автоматически. Хотя методы, которые я описал в этой статье, работают в большинстве случаев, бывают ситуации, когда служба может быть настроена на автоматический запуск, но не запускаться даже после неоднократных попыток запуска службы вручную. В этой статье я хочу рассмотреть некоторые основные причины и решения.

Чтобы показать вам, как решить проблему такого типа, я хочу провести вас через процесс диагностики на одной из виртуальных машин в моей лаборатории. У меня есть виртуальная машина, на которой работает System Center 2016 Virtual Machine Manager. По какой-то причине служба System Center Virtual Machine Manager не запускается автоматически при загрузке системы. Попытка вручную запустить системные службы приводит к длительной задержке, за которой следует ошибка 1053, указывающая на то, что служба своевременно не ответила на запрос запуска или управления. Вы можете увидеть, как выглядит ошибка на рисунке ниже.

Если вам интересно, 1053 — это общая ошибка, не относящаяся к System Center Virtual Machine Manager. Это может быть вызвано как системными службами, которые не запускаются, так и системными службами, которые не могут быть остановлены.

Упрямые системные службы: сначала ознакомьтесь с основами

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

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

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

Исправление проблем

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

Чтобы проверить зависимости службы, откройте Диспетчер управления службами, щелкните правой кнопкой мыши службу и выберите команду «Свойства» в контекстном меню. Откроется страница свойств службы. Теперь перейдите на вкладку Dependencies листа свойств, которую вы можете видеть на рисунке ниже.

Теперь все становится интереснее. Если вы посмотрите на рисунок выше, то увидите, что у этого сервиса нет зависимостей. Причина, по которой это так интересно, заключается в том, что это служба System Center Virtual Machine Manager, а System Center Virtual Machine Manager определенно имеет зависимости. Некоторые из зависимостей, например, включают Active Directory и SQL Server. Вы можете увидеть список зависимостей здесь.

Если служба System Center Virtual Machine Manager содержит список зависимостей, то следующим шагом в этом процессе будет проверка того, запущены ли эти службы зависимостей, и запуск этих служб при необходимости. Однако в этом случае зависимости существуют на уровне приложения, а не на уровне службы. Тем не менее, есть что-то, что мешает запуску службы.

Проверьте журналы событий

Учитывая, что мы еще не знаем, что мешает запуску службы, следующая логическая вещь, которую нужно проверить, — это журналы событий. В моем случае журналы содержат довольно бесполезное событие, которое просто говорит о том, что VMM столкнулся с критическим сбоем и завершит процесс. Вы можете увидеть реальную ошибку ниже. Другими словами, мы пытаемся запустить службу, но служба сталкивается с критическим сбоем и останавливает основной процесс.

Однако если вы внимательно посмотрите на текст события, вы заметите, что в нем упоминается файл журнала. Вы можете увидеть часть файла журнала на рисунке ниже.

Базовое исключение в этом файле журнала указывает, что ExecuteReader требует открытого и доступного соединения и что текущее состояние соединения закрыто. Далее в файле журнала (не показанном на снимке экрана) есть ссылки на SQL Server. Следовательно, кажется вероятным, что проблема может быть связана с зависимостью VMM от SQL Server.

Оглядываясь на диспетчер управления службами, я вижу, что SQL Server не запущен, как показано на рисунке ниже.

К счастью, у меня нет проблем с запуском SQL Server вручную. Когда SQL Server запущен, VMM также может запуститься, как показано ниже.

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