Background: Apparently, based on JIRA ticket below there are no options to run more than one gradle processes on the same project on the same cache:
https://issues.gradle.org/browse/GRADLE-1991
My build contains couple "tasks" that using JavaExec are starting new processes to do some job (not related to build itself).
I have more than one of such tasks, and I need to run them in parallel. But cause of issue above - can't
> Could not open buildscript class cache for build file 'C
rpd407vnbbns8c3t51r39r\ProjectScript\buildscript).
> Timeout waiting to lock buildscript class cache for b...
Owner PID: unknown
Our PID: 15860
Owner Operation: unknown
Our operation: Initialize cache
What are my options?
Ideal solution for me is to run those processes without keeping parent process (let it finish). Is it possible?
Related
> Could not create service of type FileAccessTimeJournal using GradleUserHomeScopeServices.createFileAccessTimeJournal().
> Timeout waiting to lock journal cache (/Users/mark/.gradle/caches/journal-1). It is currently in use by another Gradle instance.
Owner PID: 7366
Our PID: 7609
Owner Operation:
Our operation:
Lock file: /Users/mark/.gradle/caches/journal-1/journal-1.lock
I have two repos on my mac that I am trying to run at the same time with gradle bootRun. I can run one of them fine, but when I run the other I get this message. I have never seen this before when running two repos with gradle. I have tried using gradle --stop, deleting my caches file in gradle, removing "*.lock" file, and restarting the daemons. Nothing works.
What is happening?
close your android studio and just delete
/Users/mark/.gradle/caches/journal-1/journal-1.lock
this file, and test again
You can kill the gradle proccess stucked:
sudo kill -9 <Owner PID>
In your case:
sudo kill -9 7366
When I try to run 2 gradle projects simultaneously, it throws me the following error:
Could not create service of type FileHasher using GradleUserHomeServices.createCachingFileHasher().
Timeout waiting to lock file hash cache(/Users/username/.gradle/caches/6.4/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 40300
Our PID: 44136
Owner Operation:
Our operation:
Lock file: /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock
I have read that the best solution is to kill practically all the java processes with the command "killall -9 java" or some derivative that kills the process that prevents the new application from starting, and yes, when I finish an application I can start any of the others , but the thing is that I actually need to run 3 applications that communicate with each other on my local machine, but when I run the first one, the other 2 give me that error.
I'll answer my own question in case someone finds it useful:
The solution is to specify a different gradle-user-home for each job. Specifically, setting it to the current working directory. (i.e. project directory) and you can do it whit the following command:
./gradlew -g $PWD <build (or bootRun or etc the command you need)>
Exception:
Could not create service of type FileHasher using GradleUserHomeServices.createCachingFileHasher().
Timeout waiting to lock file hash cache(/Users/username/.gradle/caches/6.4/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 40300
Our PID: 44136
Owner Operation:
Our operation:
Lock file: /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock
Removing lock file worked for me
rm /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock
Yesterday all of the sudden my projects on a Windows 10 machine stopped running in parallel due to file lock timeouts.
All my projects are using gradle-wrapper and provide a run task
When I start the 1st run-task, it work normally, but any following run-tasks break with the error like this:
> .\gradlew run
Starting a Gradle Daemon, 1 busy and 4 stopped Daemons could not be reused, use --status for details
FAILURE: Build failed with an exception.
* What went wrong:
Gradle could not start your build.
> Could not create service of type FileAccessTimeJournal using GradleUserHomeScopeServices.createFileAccessTimeJournal().
> Timeout waiting to lock journal cache (C:\Users\injec\.gradle\caches\journal-1). It is currently in use by another Gradle instance.
Owner PID: 16440
Our PID: 12216
Owner Operation:
Our operation:
Lock file: C:\Users\injec\.gradle\caches\journal-1\journal-1.lock
the --status option shows:
> .\gradlew --status
PID STATUS INFO
12216 IDLE 6.9.1
16440 BUSY 6.9.1
14992 STOPPED (stop command received)
7856 STOPPED (other compatible daemons were started and after being idle for 0 minutes and not recently used)
26680 STOPPED (by user or operating system)
18556 STOPPED (by user or operating system)
I tried different tricks, like switching the Gradle verison 5.6.1 - 6.8.3 - 6.9.1 and using the --stop option, but the error remains.
Adding the --stacktrace to the run command reveals that not only journal-1 cache is involved, but also some others dirs like modules-2.
I didn't do any changes to my system, apart from regular Win10 updates.
How can the problem be fixed?
TIA
It's likely that gradle process was exited abnormally and left the lock file behind. Check in the task manager if process with id 16440 exists, and if not just remove the orphan lock file C:\Users\injec\.gradle\caches\journal-1\journal-1.lock
This may be the file-system permissions of C:\Users\injec\.gradle... while you may have overseen one detail: you're calling .\gradlew instead of ./gradlew or gradlew.bat ...which means that you are not running on CMD, but on PS or WSL. gradlew.bat run would run directly on CMD.
Check .gradle file system. Gradle not works well on non-native file system. https://github.com/gradle/gradle/issues/15881
File system watching supports the following file system types:
APFS
btrfs
ext3
ext4
XFS
HFS+
NTFS
Gradle also supports VirtualBox’s shared folders.
Network file systems like Samba and NFS are not supported.
Symlinks
File system watching is not compatible with symlinks. If your project files include symlinks, symlinked files do not benefit from file system watching optimizations.
or you can disable file system watch for the build https://docs.gradle.org/current/userguide/file_system_watching.html#disable
Gradle maintains a Virtual File System (VFS) to calculate what needs to be rebuilt on repeat builds of a project. By watching the file system, Gradle keeps the VFS current between builds.
I would like to run a jar file using a robot framework test suite, because this test-case is to be included among other test cases.
When the jar is run from the cmd, it produces the expected output, which can take 10 minutes, and then it ends.
My issue is that I'm not capable to detect when the execution of the jar is finished. I tried several keywords combination, in the last attempt I used the keyword Process Should Be Stopped, as shown below, and the result is that the process is always running.
One of my doubts is: which process is running, java? or the execution of the jar?
*** Settings ***
Library Process
Library OperatingSystem
Suite Setup log running on ${properties.hostname}
Suite Teardown Terminate All Processes kill=True
Variables C:/Users/theUser/Desktop/CheckOutRegression/Regression/RegressionScripts/config/properties.py
*** Test Cases ***
Check jar execution
${data}= Start Process java -jar da-1.0-SNAPSHOT.jar importFile1.json importFile2.zip cwd=${properties.pathToScripts} alias=myProc
${wait}= Wait Until Keyword Succeeds 10x 60s Process Should Be Stopped myProc
Log ${wait}
${result}= Get Process Result myProc
Log ${data.stdout}
Do you know how I can check that the execution of the jar file is finished?
After updating Jenkins to version 2.156 (from version 1.6), some of our build jobs get stuck after completing and before moving to post-build action. Job itself is finished within 5 minutes (same as before), then it hangs for 5-10 minutes before moving on.
I managed to narrow it down to this:
"Executor #10 for master : executing 03_masa #4390" Id=34464 Group=main TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at hudson.util.ProcessTree$WindowsOSProcess.killSoftly(ProcessTree.java:560)
at hudson.util.ProcessTree$WindowsOSProcess.killRecursively(ProcessTree.java:520)
at hudson.util.ProcessTree$Windows.killAll(ProcessTree.java:666)
at hudson.Launcher$LocalLauncher.kill(Launcher.java:955)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:510)
at hudson.model.Run.execute(Run.java:1810)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Referenced code can be found here (present since version 2.141).
threadDump #1, threadDump #2
Can we do something about it?
2.141 introduced a 2min wait on process termination (it would seem that multiplies with as many processes as were created during your build)
https://github.com/jenkinsci/jenkins/commit/d8eac92ee9a1c19bf145763589f1c152607bf3ed
unsure why killSoftly does not work but you can configure the timeout
In your jenkins.xml you can add this to your /service/arguments element (before the -jar) like so:
-DSoftKillWaitSeconds=0
After doing so and restarting jenkins you should be able to find your SoftKillWaitSeconds setting under /systemInfo
and your build time should be back to normal