Подтвердить что ты не робот

Docker-> Maven-> Failsafe-> Surefire start fork завершается с ошибкой: "Разветвленная виртуальная машина завершена без надлежащего прощания. Сбой VM или System.exit?"

В соответствии с заголовком: Я пытаюсь запустить автоматизированный тест Maven из рабыни Jenkins, который контейнеризирован, и после битвы в течение недели у меня заканчиваются идеи. Он работает так же, как на экземпляре AWS с 4G ОЗУ, но в неограниченном (в RAM и CPU) контейнере он терпит неудачу с ошибкой, как показано ниже. Единственные обстоятельства, когда он запускается, - это когда я отключу forking для Failsafe-плагина, но это не вариант в будущем.

Я пробовал всевозможные опции Java/Maven/Failsafe/Surefire, которые я мог найти с помощью Google, но не повезло (например, добавление глобальных параметров Java -Xmx, а также каждого плагина в pom.xml).

Кто-нибудь успешно его запускал?

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

Это дампы, созданные плагином после сбоя:

безотказное-summary.xml:

<?xml version="1.0" encoding="UTF-8"?>
<failsafe-summary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-sure
fire-plugin/xsd/failsafe-summary.xsd" result="254" timeout="false">
    <completed>0</completed>
    <errors>0</errors>
    <failures>0</failures>
    <skipped>0</skipped>
    <failureMessage>org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM cras
h or System.exit called?
Command was /bin/sh -c cd /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle &amp;&amp; /usr/lib/jvm/java-1.8-openjdk/jre/bin/ja
va -Dfile.encoding=UTF-8 -jar /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle/target/surefire/surefirebooter81206735832436906
05.jar /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle/target/surefire 2017-10-10T15-02-35_189-jvmRun1 surefire59539140137458
58339tmp surefire_03559885505222114015tmp
Error occurred in starting fork, check output in log
Process Exit Code: 1
       at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
       at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
       at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
       at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
       at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
       at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
       at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
       at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
       at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
       at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
       at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
       at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
       at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
       at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
       at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
       at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
       at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
       at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
       at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:498)
       at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
       at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
       at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
       at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
</failureMessage>
</failsafe-summary>

2017-10-10T15-02-35_189-jvmRun1.dump:

# Created on 2017-10-10T15:02:36.303
Killing self fork JVM. Maven process died.
4b9b3361

Ответ 1

Попробуйте понизить до Surefire 1.18.1. Сегодня я столкнулся с этим вопросом и провел пару часов, пока не легко понять, почему новые версии Surefire ломаются под Docker.

* Обновление *

У меня возникла проблема с Alpine linux, но при использовании базового образа Ubuntu или Debian все было в порядке. Итак, что-то в 1.21 нарушает совместимость с некоторыми операционными системами.

Ответ 2

Я столкнулся с той же проблемой в следующей среде: docker image from alpine 3.7, maven surefire plugin version 2.21.0.

Основная причина этого описана в SUREFIRE-1422: surefire пытается использовать ps -p для проверки разветвленного процесса. Решение для меня заключалось в том, чтобы добавить procps:

RUN apk add --no-cache procps

Ответ 3

Я знаю, что это было какое-то время, но добавлю свое решение проблемы, которая заняла у меня более одного дня в FIX.

Проблема: я выполняю свои интеграционные тесты в PaaS в док-контейнере и не контролирую распределение памяти для моего процесса. поведение по умолчанию для failsafe/surfire - форкнуть JVM и запустить тесты на нем. Я не смог найти способ контролировать выделение памяти для этой раздвоенной JVM, и тесты продолжали давать сбои с ошибкой "Произошла ошибка при запуске fork", а в журналах в зависимости от того, какая версия отказоустойчивый я пытался.

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

Чтобы отключить разветвление, достаточно просто установить forkMode в конфиге:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <configuration>
        <forkCount>0</forkCount>
    </configuration>

.....

ОБНОВЛЕНИЕ: После предоставления этого решения кажется, что теперь вы можете передавать параметры разветвленной JVM, поэтому более раннее решение не требуется.

Из документов maven в разделе Forked Test Execution:

С argLine свойства argLine вы можете указать дополнительные параметры, которые будут передаваться разветвленному процессу JVM, такие как настройки памяти. Переменные системных свойств из основного процесса maven также передаются разветвленному процессу. Кроме того, вы можете использовать элемент systemPropertyVariables чтобы указать переменные и значения, которые будут добавлены в системные свойства во время выполнения теста.

https://maven.apache.org/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html

Ответ 4

Мы внезапно столкнулись с одной и той же проблемой, но только на нашем конвейере CI/CD (gitlab). Сообщение об ошибке:

error occurred in starting fork, check output in log
Process Exit Code: 1
org.apache.maven.surefire.booter.SurefireBooterForkException: 
The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

Оказалось, что это связано с новой версией образа докеры OpenJDK.

Установка свойства useSystemClassLoader в false useSystemClassLoader проблему:

   <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${maven-surefire-plugin.version}</version>
    <configuration>
      <includes>
        <include>**/*Test.java</include>
      </includes>
      <useSystemClassLoader>false</useSystemClassLoader>
    </configuration>
  </plugin>

Ответ 5

У нас была такая же проблема при использовании весеннего ботинка с верной версией 2.21.0 на альпийском языке с докером (zenika/alpine-maven). Как упоминалось ранее, понижение до 2.18.1 может быть вариантом и решить проблему разветвления vm, но вызвало новые проблемы с несовместимостью между различными версиями slf4j. Таким образом, мы сделали явное обновление до версии 2.22.1, которая решила проблему в нашем случае.

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

Ответ 6

Просто поразите ту же проблему при создании внутри maven: 3.5.4-jdk-8 с помощью surefire 2.21.0. Модернизация уверенности не помогла, но отключение форкинга, наконец, сделало трюк.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.1</version>
    <configuration>
        <forkCount>0</forkCount>
    </configuration>
</plugin>