Мейвен уверен, что огонь внезапно начал давать сбой

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

Maven 3.3.9
Oracle JDK 1.8 u144

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18.1</version>
</plugin>

Я попытался добавить параметры -e и -X, даже увеличив уровни журналов, и единственное сообщение, которое я вижу в журналах, это:

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:9c6abc2:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
    ... 31 more
Caused by: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?

Это список вещей, которые я пробовал (все из Переполнение стека):

  • 3.0.0-М3
  • версия 2.21.0
  • reuseForks=false
  • useSystemClassLoader = ложь
  • отделка стека трассировки = ложь
  • argLine=Xmx2048m -XX:MaxPermSize=512m, попытался увеличить память, потому что я думал, что разветвленная виртуальная машина дает сбой
  • useSystemClassLoader=true и useManifestOnlyJar=false
  • Oracle Java 8 u144
  • Oracle Java 8 u141

Еще одна вещь, которую я заметил, заключается в том, что при выполнении разветвленной JVM кажется, что «argLine» не передается. Например, это из журналов:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Forking command line: /bin/sh -c cd /data/apps/jenkins/workspace/Build_Deploy_Full_Dev/myapp/core && /data/apps/java/jdk1.8.0_144/jre/bin/java -jar /data/apps/jenkins/workspace/Build_Deploy_Full_Dev/myapp/core/target/surefire/surefirebooter1916960086357827445.jar /data/apps/jenkins/workspace/Build_Deploy_Full_Dev/myapp/core/target/surefire/surefire2156897915383473994tmp /data/apps/jenkins/workspace/Build_Deploy_Full_Dev/myapp/core/target/surefire/surefire_03179213296845219723tmp

Как видно, командная строка для вызова разветвленной JVM не имеет аргументов. Кроме того, как последнее уточнение, мои тесты не вызывают никаких вызовов, таких как «System.exit». Буду признателен за любую помощь!

Пожалуйста, проверьте, может ли помочь следующая ссылка: stackoverflow.com/questions/23260057/…

Anshul Singhal 30.05.2019 06:22

Во-первых, вы не показали полный журнал, потому что я предполагаю, что у вас есть неудачные тесты, кроме того, что ваш вывод выглядит особенно странно org.apache.maven.plugins:maven-surefire-plugin:9c6abc2:test ..?

khmarbaise 30.05.2019 14:26

Никаких провальных тестов. Остальной лог не имеет значения, ошибок больше нет.

Perimosh 30.05.2019 14:57

@khmarbaise, эта странная версия из моих журналов была решена. Были некоторые дополнительные модули, в которых не указывалась верная версия. Следовательно, maven попытался загрузить последнюю версию плагина с нашего сервера Nexus. В нексусе была какая-то странная версия 9c6abc2, почему я не могу объяснить. Во всяком случае, вот что я сделал: я удалил свою папку .m2 для плагина surefire, я исправил свои помпы, чтобы использовать версию 2.18.1, а затем снова запустил сборку. Та же ошибка все еще происходит, но, по крайней мере, она говорит о версии 2.18.1.

Perimosh 31.05.2019 19:57

Обновите плагин surefire до версии 2.22.2... и повторите попытку...

khmarbaise 31.05.2019 21:21

есть ли причина не обновляться до 3.0.0-M3?

Perimosh 31.05.2019 21:24

мой плохой, вы правы, 2.22.2 самая последняя

Perimosh 31.05.2019 21:25

Хорошо, мы сузили тему. Это Дженкинс. Если мы выполним сборку mvn за пределами Jenkins и даже с того же экземпляра сервера, сборка будет работать нормально.

Perimosh 31.05.2019 23:33

Может быть, ОС убивает созданную виртуальную машину из-за нехватки памяти? Jenkins (+дочерние процессы, то есть JVM) явно прожорливы в памяти. Можете ли вы проверить, используя dmesg из строки cmd?

Daniele 01.06.2019 18:48

К сожалению, я не владею этим сервером. Я попросил команду, которой принадлежит сервер, увеличить память на всякий случай. Спасибо!

Perimosh 03.06.2019 19:17
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
10
134
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я запускал сборку с того же сервера, на котором установлен Jenkins, но из-за пределов Jenkins, то есть из командной строки. Я получил успешную сборку, которая указала мне, что ни maven, ни мои зависимости не были частью причины проблемы. После перезапуска сборка заработала нормально.

Другие вопросы по теме