Pull to refresh

Comments 13

Как много времени заняло расследование? Месяц?
Суммарно проблема с непонятным «пропаданием» jenkins'а ночью у нас существовала месяцев 8, в какие-то месяцы она практически не проявлялась, а в какие-то повторялась через день. Кстати, как оказалось, эта история ещё не закончена — мы обнаружили, что уже несколько раз процесс java.exe, на котором «висит» Jenkins был убит процессом C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTAgent32.exe. Так что ждите второй части статьи )
В качестве сборочной системы мы используем Jenkins, который настроен на регулярный ночной запуск, в том числе, и тестеров. Запуск самого Jenkins производится из cmd-файла командой

А зачем Jenkins перезапускать каждую ночь? Почему нельзя агент запустить и использовать встроенные механизмы запуска Jenkins (scheduled trigger/cron)? Агент оставить как пользовательское приложение. Или я что-то не так поянл
Это я, наверное, не совсем понятно написал. Имелось в виду «Jenkins запускает по ночам много чего, включая тестеры». А вот костыль с регулярным перезапуском Jenkins при падении действительно был прикручен после появления описанной в статье проблемы. Надеюсь, больше он не понадобится.
А зачем Jenkins перезапускать каждую ночь?

Jenkins не перезапускается каждую ночь, а только при загрузке системы. Скрипт, про который говорилось в статье, каждые полчаса проверяет, запущен ли jenkins, и перезапускает его, если он по какой-то причине закрылся (или был закрыт), т.к. мы не знали причину, по которой Jenkins закрывался по ночам во время прогона тестов.

Почему нельзя агент запустить и использовать встроенные механизмы запуска Jenkins (scheduled trigger/cron)? Агент оставить как пользовательское приложение. Или я что-то не так поянл


Если вы про master\slave агентов при распределённой сборке, то мы просто не использовали эту архитектуру — у нас один сборочный сервер для Windows и один для Linux и они не связаны (на каждом независимая конфигурация Jenkins), и такой задачи просто не стояло. Но даже бы если мы использовали агентов для распределённой сборки, это ведь, как я понимаю, всё-равно не помешало бы стороннему процессу «убивать» java.exe master'а, как это и происходило у нас.
Интересно. :) А у вас никакой системы логирования не используется внутри SelfTester-a?
Есть. Но она ориентирована на выявление проблем другого характера, связанных с запуском анализатора и выданных им результатов.
Но она ориентирована на выявление проблем другого характера


Теперь в тестере появилась система логгирования и для «убийства» зависших процессов — мы добавили её как раз, когда узнали, что «виноват» SelfTester.
Что мешает использовать WaitForSingleObject/WaitForMultipleObjects применительно к хэндлу запущенного процесса(-ов)? Гарантированно получите событие завершения.
Ничто не мешало, просто «так получилось» :) Как упоминалось в статье, тестер разрабатывался, когда у нас ещё не было «полноценной» консольной версии анализатора, и для ночных запусков использовался devenv.exe (процесс Visual Studio с плагином нашего анализатора). А т.к. это не консольное приложение, с его unattended запуском было много ньюансов — например какой-то сторонний messagebox мог запросто заблокировать всю ночную сборку. Поэтому и был написан код, который ориентировался на появление на диске файла-лога анализа и считал, что после этого devenv можно по истечению определённого timeout'а «убивать», как зависший.

Когда появился полноценный cmd анализатор, в тестере просто поменяли вызов devenv.exe на PVS-Studio_Cmd.exe, оставив всю эту логику — ведь «всё уже отлажено и работает» :)
А вы не пробовали создать Job, присоединить к нему запускаемый процесс — а в конце теста просто прибить весь Job целиком через TerminateJobObject?
Sign up to leave a comment.