Как я со службой планировщика заданий WebSitePanel боролся

Прилетела нам заявка от пользователя, что перестали у него в WebSitePanel работать запланированные задачи. Когда перестали работать не известно. Скорее всего, когда мы обновили панель до новой версии (с 2.0 до 2.1). В новой версии панели, разработчики решили вывести службу планировщика заданий в отдельный сервис Windows. Раньше он был частью Enterprise сервера.

Думаю, скорее всего вылетела эта служба, захожу на сервер смотрю, действительно служба остановлена. Запускаю. Думаю ну все ОК, готовлюсь отписаться клиенту, смотрю процессы – службы нет, обновляю оснастку services – служба остановлена. Для верности пробую запустить ее еще раз, тот же результат.

Захожу, посмотреть что пишет просмотр событий, появляется два события, первое что служба была неожиданно завершена, второе что :

Application: WebsitePanel.SchedulerService.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.NullReferenceException

Stack:

at WebsitePanel.EnterpriseServer.Scheduler.RunBackgroundTask(WebsitePanel.EnterpriseServer.BackgroundTask)

at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

at System.Threading.ThreadHelper.ThreadStart()

Очень информативно… Лезу на форумы, там рекомендуют сравнить файлы конфигурации Enterprise сервера (web.config) и файлы конфигурации шедулера - WebsitePanel.SchedulerService.exe.conf, в них должны быть одинаковые строки подключения и ключей шифрования.

Сравниваю, в конфиге шедулера нет ключей шифрования. Довольный как слон, вставляю ключ, сохраняю кофиг, захожу в службы, запускаю, проверяю. Хрен!!! Служба остановлена. В логах ни чего не поменялось.

Еще рекомендуют сравнить версии dllок, сравниваю, все одинаково.

Ну думаю, может переустановить этот шедулер? Запускаю установщик, он его не видет, предлагает установить заново. Немного понервничал, как бы установщик не грохнул Enterprise Server (т.к. он должен быть не активный в установщике, что бы не переписать нужные файлы), решился на установку, предварительно удалив вручную службу, и все файлы планировщика. Безрезультатно.

Предполагаю что дело в .net. На сервере стоит 4.5, в конфигах везде фигурирует 4.0. Поигрался с конфигами, попробовав в них изменить версию. Служба не может стартануть, ругается на неизвестную версию .net.

Ладно. Предполагаю, что нужно установить чистую версию .net 4, удаляю .net 4.5, заодно устанавливаю все апдейты на сервер, их накопилось около 70 штук. Перезапускаю сервер, потирая руки, что апдейты и смена версии .net поможет… То же самое.

Пока думал, что делать дальше, создал пару тестовых задач, и начал запускать службу. И обнаружил, что одна из задач успешно успела выполниться один раз, из 10 запусков задачи и службы. Хм…

Ок, думаю пора посмотреть что происходит в базе данных, захожу на сервере в базу, а там…

…Черт ногу сломит от количества таблиц, посмотрел по названиям, где фигурирует Schedule, посмотрел что в таблицах, ничего такого не увидел. Увидел что все задачи хранятся в таблице Schedule, и там указаны ID хостинг спейсов кому эти задачи принадлежат. Здесь же можно их отключить изменив колонку Enabled.

Думаю нужно попробовать все задачи отключить и посмотреть, будет ли вываливаться служба. Захожу на страницу панели, в ней перехожу в хостинг спейс по его ID, отключаю задание. Что бы удостовериться, что именно в эту таблицу внесется изменение о включении/отключении задания. Да изменение внеслось. Сохраняю текущее состояние таблицы в файл, и sql командной "Update Schedule set Enabled=0 Where Enabled=1" отключаю все задания.

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

Думая, что больше проблем с SQL быть не может ,иду на сервер с шедулером. Запускаю службу, хрен там… Ошибка та же…

ОК, WebSitePanel – проект с открытым исходным кодом, качаю исходники с гитхаба, нахожу в проекте код по сервису Scheduler. В нем нахожу где вызывается метод RunBackgroundTask(), добавляю на него обработчик исключений, компилирую, копирую новые dll ки на сервер, запускаю службу, служба остановлена. Но ошибка уже другая:

Application: WebsitePanel.SchedulerService.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.NullReferenceException

at WebsitePanel.EnterpriseServer.Scheduler.RunBackgroundTask(WebsitePanel.EnterpriseServer.BackgroundTask)

at WebsitePanel.EnterpriseServer.Scheduler+<>c__DisplayClass3.<RunManualTasks>b__1()

at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

at System.Threading.ThreadHelper.ThreadStart()

Нахожу, где в коде вызывается метод RunManualTasks, и добавляю на эту богодельню обработчик исключений. Компилирую, служба не вылетает, но и не работают ни фига ни какие задания…

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

Решаю запустить обновление базы, которое запускалось при обновлении базы до 2.1, и посмотреть на ошибки, серьезных ошибок нет, и они не связаны с хранимыми процедурами, значит, и хранимые процедуры должны быть в порядке, т.к. они обновляются этим обновлением.

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

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

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

В задании был указан ID хостинг спейса его создавший и вызвавший. Сравнил с таблицей хостинг спейсов, а хостинг спейса то такого нет… Поэтому вначале, когда смотрел на таблицы scheduler, я и не заподозрил что может быть неладное, с базой данных. Т.к. для всех хостинг спейсов я задания отключил, и ни как не мог предположить, что в базе может зависнуть задание, после удаления пользователя.

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

Вот такие вот, трудовые будни. =)