IntelliJ IDEA 2021.1 and 2021.2 leaves the Gradle Daemon running when I exit the program. I would like to know if there is a way to momentarily stop or restart the Gradle Daemon from within IntelliJ without exiting. Gradle has a lock on files that doesn't go away when simply closing IntelliJ. The only way to get it to release the lock is to run gradle --stop from the version of Gradle that is currently running. The approaches I've found so far are far less than ideal. I'll share them in case they help anyone else, but I'm hoping there's a better way.
If I manually browse to my User Home.gradle\wrapper\dists\gradle-x.y.z-all<hash>\gradle-x.y.z\bin for the version of Gradle that I know IntelliJ is using, then I can manually run that gradle command with --stop flag and it will stop the daemon. So, yeah I guess I could create a batch script for this, but the fact that it is stored in such a buried directory involving some sort of hash code, I don't really want to have to change this script for different systems.
In InteliJ IDEA, If I click the "elephant" looking button at the top of the gradle menu called "Execute Gradle Task" it brings up a command line that starts with "gradle", but it only accepts established task names, it doesn't accept "gradle --stop". It gives the error Unknown command-line option '--stop'.
As a less than ideal work around, I have copied the gradle-x.y.z folder from near the end of that path to c:\Gradle\ and I have added that version's bin folder to the PATH environment variable. So, at least, I can open up a command prompt and run gradle --stop for now. This becomes problematic when I want my default / command line accessible gradle version to be different from the project I am working on. Yeah I could create a bunch of custom batch scripts that point to all different versions. That doesn't sound like fun. I have a hard time believing that I can't do something within IntelliJ to get the currently running gradle daemon to shutdown.
IDE does not kill Gradle daemon, because this demon can be reused by another build, including when doing a build from the command line.
There is an action Show Gradle Daemons (you can call it from Help | Find Action action):
It will show you the list of Gradle daemons with the ability to stop them:
I'm trying to upgrade an existing project from gradle 6.5.1 to 6.6.
But when I build, it fails with an error:
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.116 secs.
The client will now receive all logging from the daemon (pid: 122). The daemon log file: /home/****/.gradle/daemon/6.6/daemon-122.out.log
Starting build in new daemon [memory: 519.0 MB]
Using 1 worker leases.
Starting Build
Compiling initialization script '/home/****/agent/workspace/Enrich_build_PR-41#tmp/artifactory/init-artifactory449129576487257952gradle' using SubsetScriptTransformer.
FAILURE: Build failed with an exception.
* What went wrong:
Failed to create Jar file /home/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
> Prefix string too short
Running with --debug, the only thing that looks relevant is:
020-10-05T16:38:54.631+0000 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Selected match ok from candidates [ok] for {org.gradle.dependency.bundling=external, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}
Which seems like an internal gradle issue. How can I fix or avoid this error?
(I also tried 6.6.1 and have the same problem)
It happens when I run "./gradlew help" as well, so it shouldn't be related to my build config.
The stacktrace looks like:
* Exception is:
org.gradle.api.GradleException: Failed to create Jar file /home/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:47)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:76)
at org.gradle.internal.classpath.InstrumentingClasspathFileTransformer.transform(InstrumentingClasspathFileTransformer.java:70)
at org.gradle.internal.classpath.DefaultCachedClasspathTransformer$TransformFile.lambda$schedule$0(DefaultCachedClasspathTransformer.java:261)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.IllegalArgumentException: Prefix string too short
at org.gradle.internal.classpath.ClasspathBuilder.buildJar(ClasspathBuilder.java:53)
at org.gradle.internal.classpath.ClasspathBuilder.jar(ClasspathBuilder.java:45)
... 6 more
Your issue seems to be related to artifactory plugin
Check https://github.com/jfrog/jenkins-artifactory-plugin/issues/349
Quick Fix
Recommend to downgrade to Gradle 6.5 to resolve the issue.
Further Details / Possible Cause
While I don't know the root cause of why this happens, I get the same 'Prefix string too short' error, in Gradle 6.6.1.
And in particular, this is my exact error message, from a Mac:
Failed to create Jar file /Users/****/.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok.
Since the 'prefix' error came from Java, I looked at my Java install thinking that might be the problem. In my case Java was many versions behind, so I upgraded to 8u261 however that didn't seem to change anything.
For how it starts in our case:
User kicks off Jenkins job for Gradle
Jenkins job fails specifically for being unable to create the file in the cache directory. And the number actually is the same each time for the cache too; it's always '.gradle/caches/jars-8/8535adf040d7c5fdb7fd6bc28bb0ef3f/ok' and not a different number. So it's almost like that is statically set from somewhere.
So focusing on that error, I came across this similar-ish prefix error, for a Java issue. While this doesn't fully answer the issue we see, it does help explain why it could be a 'legitimate' error as it thinks the file name is less than 3 characters.
https://stackoverflow.com/a/48806741/14403001
So it feels like it's interpreting the end of that string as being the file name. Namely it might think that ok at the end of the path is actually a filename, and being less than 3 characters it sends the 'Prefix string too short' error. Keep in mind this is speculation and I don't know if this is actually the cause or not.
We happened to have another Mac that was running Gradle 6.5 that was working fine with the exact same Jenkins job. So we downgraded from Gradle 6.6.1 to 6.5 to match the other and are back working like before.
Since we used Mac, Brew didn't actually have an older version to roll back to. So I was forced to uninstall gradle via brew, then follow the steps below to install and point to an older version of Gradle.
Hoping it's easier for you via yum/apt to downgrade than it was for myself.
https://gradle.org/install/#manually
I am using IntelliJ Idea 2017.3 and on any Gradle project (even for simple 'hello world' from GitHub) I always got next error:
"Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/3.5-rc-2/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error: Could not find or load main class 1.8"
Meanwhile, if I run an application with Gradle wrapper (gradlew.bat in my case) everything works perfectly. For me it looks like misconfiguration issue, but I cannot find what I am doing wrongly in Idea configuration or any other place. I appreciate any help with it or clue where to dig.
The issue was resolved and I would like to share this knowledge with all those who encounter a similar problem.
In my case, I had to delete two configuration files gradle.experimental.xml and gradle.settings.xml from IDEA configuration directory %IDEA_HOME%\config\options. I suppose they were created at the time when I installed Gradle globally on my PC. Somehow these settings were persisted, even after I removed globally installed Gradle and started to use Gradle's wrapper.
I'm new to Gradle and while trying to install Gradle in my PC with Windows OS, I got the below mentioned error
Error: Could not find or load main class org.gradle.launcher.GradleMain
Only thing I did is that I followed the gradle installation steps given in gradle site Gradle installation and typed
gradle -v
in command prompt and I got the above mentioned exception. Any clue as to what had happened and how to resolve it.
This is what I have done :
Downloaded the zip file
Copied 'gradle-3.5' from the zip file to a folder I created in C drive (C:\Gradle)
Set GRADLE_HOME to 'C:\Gradle\gradle-3.5'
Set Path to '%GRADLE_HOME%\bin'
Opened cmd and typed gradle -v and got this error
I stopped all gradle daemons by running ./gradlew --stop and the error was resolved for me.
Basically this means that Gradle can't find your gradle/wrapper/gradle-wrapper.jar.
You have to follow Step 3 and setup environment variables:
Microsoft Windows users
In File Explorer right-click on the This PC (or Computer) icon, then
click Properties -> Advanced System Settings -> Environmental
Variables.
Under System Variables select Path, then click Edit. Add an entry for
C:\Gradle\gradle-3.5\bin. Click OK to save.
Source: https://gradle.org/install#configure
The easiest way, is to simply use gradlew.bat in your project and it will auto download Gradle for you!
I had the same issue after I removed the cache, the Gradle worker was running and I was getting this error
Error: Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
Steps I performed to resolve the error
Use gradle --stop or ./gradlew --stop
Delete the workerMain.lock file under $USER/.gradle/caches/version/workerMain
re-run the Gradle command
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
For me, killing the Gradle daemon (gradle --stop) really helped and fixed the issue.
Try setting your GRADLE_USER_HOME variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch/mkdir anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~ home directory (gradle_2_3_cache). This will help me in case I have another job/build run running on the same Slave machine but with a different Gradle version for ex: 2.5 etc version and if I want the .gradle cache for 2.3 and 2.5/x version in separate folders.
NOTE: When using parallel section within Jenkinsfile, it's best to avoid Gradle greatness (i.e. using same Gradle's cache i.e. using same GRADLE_USER_HOME) as otherwise, you'll land into a mine of interesting issues as listed here: Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits & Gradle error: Task 'null' not found in root project
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
Restarting the machine solved the issue.
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew, gradlew.bat and gradle/wrapper/*) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
I got the same error, got rid of it by using the correct version of Java / JDK. I was trying to build a Java 8 project with the Java 11 JDK. Check which version of Java JDK you are using.
To develop projects with different Java versions in parallel I now use jEnv to manage the different JDK versions: http://www.jenv.be/
This is a permission issue.
do a
gradle wrapper --stacktrace
you should see something like this
Failed to create parent directory '/home/cloud_user/my-project/gradle' when creating directory '/home/cloud_user/my-project/gradle/wrapper'
the user, cloud_user, has no permission to the directory
make cloud_user owner of the folder
sudo chown -R cloud_user:cloud_user /home/cloud_user/my-project/
I got this error when running code in IntelliJ Idea, and
gradle --stop
really not helped, as it said that "No Gradle daemons are running."
But simple kill of all gradle processes helped:
ps aux | grep gradle
kill -9 $PID
Permission issue. This fixed the issue for me:
sudo chown -R $USER dir
For me this was to do with Java versions. I have Java 10 installed and as the default Java on my system. Setting a JAVA_HOME pointing at Java 8 was sufficient for the project (graphql-spring-boot) to build.
If using the "Invoke Gradle script" build step, click on Advanced to reveal additional options. Locate "Force GRADLE_USER_HOME to use workspace" and check it.
If anyone is still struggling with this, my issue was caused by Microsoft preventing Java from running due to Controlled Folder Access security restrictions.
I didn't get the popup notification since my computer is set to Do Not Disturb Mode. Once I allowed access, Gradle ran fine.
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME did not work. I had to change the filesystem to be read/write.
You Just Have to Run it under the super user (sudo ....) it works for me
If you run Docker-in-Docker and mount the project directory from docker host directly to docker container:
-v ${PWD}:/path_to_project -w /path_to_project
the owners are different and docker container user (either gradle or root) can't override/delete ./buildSrc/build or ./build/
One of the fixes - copy the sources inside the container to temporary directory and build there.
Smth like this (first mounted to project, but then copied to project-copy to "decouple" with the host system real files and run the build in the copy):
docker run -v "${PWD}":/home/gradle/project -w /home/gradle/project-copy \
--rm \
--entrypoint sh \
gradle:5.5.1-jdk11 \
-- -c "cp -r -T /home/gradle/project ./ && ./gradlew build"
In my case I had bad credentials to private Maven repository. JIdea does not show the inner exception but running gradle build reveals the problem immediately.
I used a Gradle project in Eclipse, Eclipse's Gradle was giving that error. When I installed NetBeans and its Gradle Plugin, the problem has gone, project was building okay. Another way to circumvent this error was using commandline ./gradlew , project also built successfully.
It seems that Eclipse's era is over, they appear to be unable to follow the progress.
This can happen if you run Gradle commands from separate terminals at the same time - I assume Gradle somehow locks ~/.gradle when it is running to prevent any problems.
I had that same error, while running gradle with java 14 (openjdk) as my default java implementation. Setting default java back to java 8 solved the issue
sudo update-alternatives --auto java
just run (taskkill /im java.exe /f) in command
In my case the error was different but I landed here, my error was:
Could not create service of type ExecutionHistoryStore using ExecutionGradleServices.createExecutionHistoryStore().
> Timeout waiting to lock execution history cache (/Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 94001
Owner Operation: unknown
Our operation:
Lock file: /Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory/executionHistory.lock
It happens when you try to run flutter run from two separate terminals.
So I solved it by executing cd <projectPath> && flutter run from the active terminal which I was using first.
Basically, while executing some Gradle command, in this case building an android file, the terminal locks down some Gradle PID, so either you stop them or just simply use that terminal.
in my case manual removing the .gradle and .idea folders helped me
you can find them in the Android Studio if Project view selected
after this just clean and rebuild app
kill -9 'pid' solved the issue. pid can be found in the error log
To fix this issue, restarting your PC is the main solution
I got the same issue and for me worked below command.
./gradlew --stop
After that restart my system and wipe data of simulator and run again everything works fine.