Gradle демон сборки неожиданно исчез (возможно, он был убит или, возможно, разбился), при создании Android-проекта на Jenkins

У меня есть Android-проект, который успешно работает в Android Studio.

Теперь я хочу построить его на Дженкинсе. Но когда я делаю, я получил следующую ошибку: Gradle демон сборки исчез неожиданно (возможно, он был убит или, возможно, разбился)

Исключение:

org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
    at org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:222)
    at org.gradle.launcher.daemon.client.DaemonClient.monitorBuild(DaemonClient.java:198)
    at org.gradle.launcher.daemon.client.DaemonClient.executeBuild(DaemonClient.java:162)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:125)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:80)
    at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43)
    at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:241)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:214)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:207)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
    at org.gradle.launcher.Main.doAction(Main.java:33)
    at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
    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.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:23)

Я читаю связанные темы, но это не помогает. Я попытался создать его с помощью демона gradle и без него, но проблема все еще существует.

Ответы

Ответ 1

EDIT Похоже, что с новыми версиями Gradle произошли некоторые изменения.

Начиная с версии 3.0 вы больше не должны отключать демона вашего CI

[Мы] рекомендуем использовать [демон] как для машин разработчиков, так и для серверов непрерывной интеграции.

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

ПРЕДЫДУЩИЙ ОТВЕТ

Он рекомендовал отключить daemon на любом сервере CI. используйте этот параметр, чтобы отключить его

--no-daemon

Ответ 2

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

Я нашел ответ на форуме gradle.org, который предположил, что GradleDaemon всегда будет работать в любом случае. Флаг -no-daemon просто запустил бы эту конкретную сборку, а не оставался на неопределенный срок.

Если вы укажете аргументы JVM, требующие forking, Gradle разветкит новую JVM. Независимо от того, нужен ли вам процесс демона, выполняемый класс называется GradleDaemon. Переключатель -no-daemon должен вызывать разветвленный процесс, а не длительный процесс daemon, но он все равно будет запускать класс GradleDaemon.

Источник: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5

Возможно, я читаю это неправильно, и я не могу ручаться за достоверность ответа, но я думаю, что причиной этой ошибки является нехватка памяти для Gradle. Поскольку он всегда будет запускать GradleDaemon.

Поэтому я добавил

org.gradle.jvmargs=-Xmx1024m

к моему ~/.gradle/gradle.properties и он больше не дал мне эту ошибку.

Ответ 3

Похоже, это проблема, связанная с памятью. Тем не менее, отключение демона, предложенное Олегом, похоже, помогает.

использование

org.gradle.daemon = ложь

gradle.properties

либо в папке ~/.gradle, либо в папке проекта.

Ссылка: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

Ответ 4

В нашем случае проблема была вызвана тем, что сервер CI передавал переменные среды с символами без ascii (т.е. именами авторов фиксации).

Добавление свойств file.encoding=utf-8 в Gradle немедленно устранило проблему.

Ответ 5

gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

Или добавьте org.gradle.jvmargs=-Xmx1536m в gradle.properties файл.

Ответ 6

Никто не может столкнуться с этим, так как это довольно глупо, но...

Моя проблема была странным персонажем, присутствующим в моем сообщении о совершении... Я скопировал предыдущее сообщение о фиксации из gitlab, которое содержало emoji и вставляло его в заголовок запроса на объединение, вместо синтаксиса normal :bug:

Ответ на akru помог мне в правильном направлении 🙏

Ответ 7

Gradle build daemon disappeared unexpectedly во многих случаях, означая, что сам Gradle или даже Java потерпели крах. В моем случае это была java. Заполните отчет об ошибке: https://bugzilla.redhat.com/show_bug.cgi?id=1408857

Посмотрите на файлы с такими hs_err_pid%p.log: hs_err_pid%p.log где% p - PID процесса в каталоге, из которого вы запускаете задачу gradle.

Обновление: Похоже, сама проблема Gradle. В моем случае из-за использования родного jansi. В выпуске предусмотрено обходное решение:

ln -sb /dev/null /home/pasha/.gradle/native/jansi/1.17.1/linux64/libjansi.so

Ответ 8

Я попробовал решение --no-daemon, но моя сборка продолжала сбой с тем же DaemonDisappearedException.

Я решил это, увеличив ОЗУ сервера, на котором я запускаю Jenkins. В AWS EC2, что означало необходимость увеличения типа экземпляра EC2, что приводит к увеличению ОЗУ.

Ответ 9

Иногда просто выполнение Build → Clean Project работает. Попробуйте, прежде чем начинать с других изменений в файле gradle.

Ответ 10

Ничего себе, в моем случае закрытие Android Studio и повторное открытие работало просто отлично, и ошибка исчезла. :)

Ответ 11

Я использовал Android Studio в Windows 7, и эта ошибка появилась. Что для меня работало, это убить Java.exe из Windows TaskManager.

Ответ 12

В моем случае я ZelixKlassMaster свой проект студии android и использую ZelixKlassMaster для запутывания своего кода, проблема в том, что мой путь к классам на Zelix был установлен на 27 но мой проект использовал android 28 Надеюсь, это поможет любым будущим посетителям. как я отлаживал, это был мой seed файл распечатывал эту ошибку

ERROR: Invalid classpath in "classpath" statement at line 69 : "C:\Users\Rab\AppData\Local\Android\Sdk\platforms\android-27\android.jar" is not a valid path.

Ответ 13

У нас такая же проблема с vsts, мы обнаружили, что это происходит, когда переменная окружения имеет символ utf8, а в ОС не установлена кодировка для .UTF-8.

Вы можете увидеть: http://www.iasptk.com/ubuntu-fix-locale-issue/

Ответ 14

Вопрос::
Демон сборки Gradle неожиданно исчез (возможно, он был убит или мог разбиться)

Решение :: перейдите к gradle.properties и введите приведенный ниже код в org.gradle.jvmargs = -Xmx1536m

org.gradle.daemon = ложь