Could not create service of type FileHasher using GradleUserHomeScopeServices.createCachingFileHasher()

6
votes

Here is the context of my problem:

  • a gitlab ci yml pipeline
  • several jobs in the same internship
  • all jobs use a task gradle requiring the use of his cache
  • all jobs share the same gradle cache

My problem:

sometimes, when there are several pipelines at the same time, I get :

What went wrong: Could not create service of type FileHasher using GradleUserHomeScopeServices.createCachingFileHasher().

Timeout waiting to lock file hash cache (/cache/.gradle/caches/5.1/fileHashes). It is currently in use by another Gradle instance. Owner PID: 149 Our PID: 137 Owner Operation: Our operation: Lock file: /cache/myshop/reunion/.gradle/caches/5.1/fileHashes/fileHashes.lock

I can't find any documentation about the lock system used by gradle. I don't understand why locks are positioned when the gradle action doesn't write to cache dir.

Does anyone know how locks work? Or can I simply change the duration of the timeout to allow concomitant tasks to wait their turn long enough before failing?

Translated with www.DeepL.com/Translator

I tried to tun gradle without a daemon, did not work.

3
gradlelockinggitlab-ci

3 Answers

6
votes

You typically get this error when trying to share the Gradle cache amongst multiple Gradle processes that run on different hosts. I assume your CI pipelines run on different hosts or they at least run isolated from each other (e.g., as part of different Docker containers).

Unfortunately, such a scenario is currently not supported by Gradle. Gradle developer Stefan Oehme wrote this comment wrt. sharing the Gradle user home:

Gradle processes will hold locks if they are uncontended (to gain performance). Contention is announced through inter-process communication, which does not work when the processes are isolated in Docker containers.

And more clearly he states in a follow-up comment (highlighting by me):

There might be other issues that we haven't yet discovered though, since sharing a user home between machines is not a use case we have designed for.

In other words: sharing a Gradle user home or even just the cache part of it across different machines or otherwise isolated processes is currently not officially supported by Gradle. (See also my related question.)

I guess the only way to solve this for your scenario is to either:

  • make sure that the Gradle processes in your CI pipelines can communicate with each other (e.g., by running them on the same host), or
  • don’t directly share the Gradle user home, e.g., by creating copies for all CI pipelines, or
  • don’t run the CI pipelines in parallel.
8
votes

I fixed this by killing all java processes in Activity Monitor(MacOS). Hope it helps.

1
votes

Another scenario where it could happen is if some of these Gradle related files are on a cloud file system like OneDrive that needs a re-authentication.

  1. Re-authenticate to the cloud file system
  2. "Invalidate caches and restart" in Android Studio