Gradle construire démon disparu de façon inattendue (il peut avoir été tués ou peut-être écrasé) lors de la construction du projet Android sur Jenkins

J'ai un Projet Android qui s'appuie avec succès sur Android Studio.

Maintenant, je veux construire sur Jenkins. Mais quand je le fais j'ai l'erreur suivante:
Gradle construire démon disparu de façon inattendue (il peut avoir été tués ou peut-être écrasé)

Exception est la suivante:

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)

J'ai lu des sujets connexes, mais ça n'aide pas. J'ai essayé de le construire à l'aide de gradle démon, et sans elle, mais le problème existe toujours.

InformationsquelleAutor Sandro Gedevanishvili | 2016-05-11
  1. 33

    MODIFIER Semble qu'il y a eu quelques changements avec les nouvelles versions de Gradle.

    Depuis la version 3.0, vous devrait de ne pas désactiver le démon sur votre CI plus

    [Nous] nous vous recommandons d'utiliser [le démon] pour les développeurs de machines et de serveurs d'Intégration Continue.

    Toutefois, si vous pensez que le Démon fait votre CI s'appuie instable, vous pouvez le désactiver pour utiliser un nouveau moteur d'exécution pour chaque version, puisque le moteur d'exécution est complètement isolé de tout les versions précédentes.

    RÉPONSE PRÉCÉDENTE

    Il est recommandé de désactiver l'option daemon sur n'importe quel serveur CI. utilisez cette option pour désactiver

    --no-daemon
    • J'ai essayé de construire sans démon, mais ensuite j'ai eu une erreur de mémoire. Lorsque j'essaie d'augmenter la limite de mémoire, j'ai reçu un Démon erreur à nouveau. Est-il possible que le serveur où jenkins est en cours d'exécution a un peu de mémoire?
    • Et j'ai construit avec --no-daemon et c'est encore de donner Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed). La plus particulière.
    • Je suis arriver la même chose, a ajouté l'option --no-démon, et ensuite de vérifier les journaux de construction, il dit explicitement de départ jusqu'démon' non-sens. Quelqu'un sait comment vraiment la tuer?
    • J'ai eu le même problème, je ne sais pas quel est le problème..
    • Je me pose exactement la même chose que vous, comment avez-vous résolu le problème?
    • Il y avait un problème avec la Mémoire sur la machine, j'ai été la construction du projet. Après une augmentation de la mémoire de la machine, le problème a été résolu.
    • C'est un malentendu ou obsolètes Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.

    InformationsquelleAutor Oleg Khalidov
  2. 11

    Après l'obtention de ce crash, j'ai essayé plusieurs choses pour obtenir le GradleDaemon d'arrêter de courir sur mon serveur CI. Aucun n'a fonctionné.

    J'ai trouvé une réponse sur un gradle.org forum qui a suggéré que le GradleDaemon serait toujours fonctionner de toute façon. L'option --no-daemon drapeau serait juste de le faire fonctionner pour ce construire, plutôt que de rester indéfiniment.

    Si vous spécifiez JVM arguments qui nécessitent une bifurcation, Gradle déviera une nouvelle JVM. Peu importe si vous voulez ou non un processus de démon, la classe qui s'exécute est appelé GradleDaemon. L'option --no-daemon commutateur doit provoquer la fourche processus à usage unique au lieu d'une longue course du processus de démon, mais il est toujours en cours pour exécuter le GradleDaemon classe.

    Source: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5

    J'ai peut-être la lecture de ce mal et je ne peux pas se porter garant de la validité de la réponse, mais je pense que la cause de cette erreur est juste un manque de mémoire pour Gradle. Comme il est toujours exécuter le GradleDaemon.

    J'ai donc ajouté 

    org.gradle.jvmargs=-Xmx1024m

    à mon ~/.gradle/gradle.properties fichier et il ne me procurait plus de cette erreur.

    • parfait, cela a aidé, merci
    • ne fonctionne pas dans mon cas.
    InformationsquelleAutor MungoRae
  3. 11

    On dirait qu'elle est liée à la mémoire de problème. Néanmoins, la désactivation du démon comme suggéré par Oleg ne semble pas aider.

    Utilisation

    org.gradle.daemon=false

    dans

    gradle.propriétés

    soit dans ~/.gradle dossier ou le projet du dossier.

    Ref: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

    • J'ai eu du mal lancement de sonarqube de mon jenkins pipeline. Avec cette option, j'ai réussi à résoudre le problème.
    • Travaillé pour mon setup de course gradle dans un conteneur docker de Jenkins
    InformationsquelleAutor muthusuba
  4. 9

    Dans notre cas, le problème a été causé par le serveur CI passant les variables d'environnement avec des caractères non-ascii (c'est à dire dans les noms de commettre des auteurs).

    Ajoutant file.encoding=utf-8 à Gradle propriétés résolu le problème immédiatement.

    • C'était exactement aussi mon cas, mais le fichier de configuration.encoding=utf-8 n'aide pas. J'ai dû supprimer les caractères spéciaux directement sur GitLab dans les paramètres de mon compte.
    InformationsquelleAutor akru
  5. 2

    Personne ne peut se lancer dans ce, car il est tout à fait stupide, mais...

    Ma question était un étrange personnage qui se présente dans mon message de commit...j'avais copié un précédent message de validation de gitlab qui contenait un emoji et collé dans le titre d'une demande de fusion, au lieu de la normale :bug: syntaxe.

    akru réponse a aidé à me diriger dans la bonne direction

    • J'ai des caractères unicode dans les variables d'environnement. Le dernier message que je vois dans le journal du démon est: 03:41:36.788 [DEBUG] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Configuring env variables: {PATH=/ et puis elle disparaît. Malheureusement pour moi, l'ajout de file.encoding=utf-8 à ~/.gradle/gradle.properties ne résout pas le problème
    InformationsquelleAutor jacoballenwood
  6. 1

    J'ai essayé le --no-daemon solution mais mon build n'ont toujours pas avec la même DaemonDisappearedException.

    J'ai résolu ce problème en augmentant la quantité de RAM du serveur, je suis en cours d'exécution Jenkins sur. Dans AWS EC2 qui signifiait d'avoir à augmenter l'instance EC2 type qui aboutit à une augmentation de la RAM.

    InformationsquelleAutor Mark Pazon
  7. 1
    gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

    Ou ajouter org.gradle.jvmargs=-Xmx1536m à gradle.fichier de propriétés.

    InformationsquelleAutor HellenGo
  8. 1

    Gradle build daemon disappeared unexpectedly dans de nombreux cas, gradle lui-même ou même java s'est écrasé.
    Dans mon cas, c'était java. Remplissez rapport de bogue: https://bugzilla.redhat.com/show_bug.cgi?id=1408857

    Regarder les fichiers nommés comme: hs_err_pid%p.log où p est le PID du processus dans le répertoire à partir de ce que vous êtes exécution gradle tâche.

    Mise à jour: Il ressemble à gradle lui-même. Dans mon cas, du fait de l'utilisation native jansi. Dans le numéro fourni de solution de contournement:

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

    J'ai été en utilisant Android Studio dans Windows 7 et ce message d'erreur est apparu. Ce qui a fonctionné pour moi est en train de tuer Java.exe à partir de Windows TaskManager.

    InformationsquelleAutor SrikanthS
  10. 0

    Parfois juste faire des Build -> Nettoyage de Projet travaux - Donner un essai avant de commencer avec les autres gradle des modifications de fichiers.

    InformationsquelleAutor shellym
  11. 0

    Dans mon cas, j'ai été mise à jour de mon android studio de projet et j'utilise ZelixKlassMaster pour obscurcir mon code à la question wa, j'ai eu mon chemin de classe sur Zelix ensemble de 27 mais mon projet a l'aide d'android 28 Espère que cela va aider tous les futurs arrivants la façon dont j'ai débogué c'était mon seed fichier a l'impression de cette erreur

    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.
    InformationsquelleAutor SamzSakerz