"Could not acquire lock(s)" during multi-threaded builds (-T 1C) #11116
Description
Affected version
3.9.9
Bug description
Using Maven 3.9.9 or Maven Daemon 1.0.2 (which I understand packages 3.9.9 internally), on a Linux Rocky 8.10 system. The fault occurs sporadically with either type of build.
We've been confused for a while about this issue because we have a master repository whose build is driven by a Makefile, and 5 of the components in that repository are isolated multi-module Maven projects with interdependencies. We've organized the Makefile dependencies so no Maven project will be built at the same time as another one when make -j is used.
However, further research and careful analysis indicates that this error does not occur between component builds, but rather, between modules within a single component build:
...
2025-09-10 12:16:02.872 [INFO] ------------------------------------------------------------------------
2025-09-10 12:16:02.872 [INFO] Reactor Summary for Java Common Project 5.3.0:
2025-09-10 12:16:02.872 [INFO]
2025-09-10 12:16:02.872 [INFO] Java Common Project ................................ SUCCESS [01:15 min]
2025-09-10 12:16:02.872 [INFO] Common Utilities ................................... FAILURE [01:31 min]
2025-09-10 12:16:02.872 [INFO] CSP ReST Client .................................... SKIPPED
2025-09-10 12:16:02.872 [INFO] ICAP Client ........................................ SKIPPED
2025-09-10 12:16:02.872 [INFO] Storage Connectors ................................. SKIPPED
2025-09-10 12:16:02.872 [INFO] HMDB Common Model .................................. SKIPPED
2025-09-10 12:16:02.872 [INFO] KMS Provider Project ............................... SUCCESS [ 5.752 s]
2025-09-10 12:16:02.872 [INFO] KMS Common Model ................................... SKIPPED
2025-09-10 12:16:02.872 [INFO] KMS AWS Provider ................................... SKIPPED
2025-09-10 12:16:02.872 [INFO] KMS NShield HSM Provider ........................... SKIPPED
2025-09-10 12:16:02.872 [INFO] General ReST Clients ............................... SKIPPED
2025-09-10 12:16:02.872 [INFO] NFSv3 RPC Client ................................... SKIPPED
2025-09-10 12:16:02.872 [INFO] Kafka Test Framework ............................... SUCCESS [03:09 min]
2025-09-10 12:16:02.872 [INFO] ------------------------------------------------------------------------
2025-09-10 12:16:02.872 [INFO] BUILD FAILURE
2025-09-10 12:16:02.872 [INFO] ------------------------------------------------------------------------
2025-09-10 12:16:02.872 [INFO] Total time: 04:26 min (Wall Clock)
2025-09-10 12:16:02.872 [INFO] Finished at: 2025-09-10T19:15:57Z
2025-09-10 12:16:02.872 [INFO] ------------------------------------------------------------------------
2025-09-10 12:16:02.872 [ERROR] Could not acquire lock(s)
2025-09-10 12:16:02.872 [ERROR] Common Utilities: Could not acquire lock(s)
2025-09-10 12:16:02.872 [ERROR]
2025-09-10 12:16:02.872 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
2025-09-10 12:16:02.872 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
2025-09-10 12:16:02.872 [ERROR]
2025-09-10 12:16:02.872 [ERROR] After correcting the problems, you can resume the build with the command
2025-09-10 12:16:02.872 [ERROR] mvn <args> -r
2025-09-10 12:16:02.872 + '[' 1 -ne 0 ']'
2025-09-10 12:16:02.872 + die 'java-common build failed!'
2025-09-10 12:16:02.872 + set +x
2025-09-10 12:16:02.872
2025-09-10 12:16:02.872 java-common build failed!
As you can see here, a few of the modules in this multi-module component succeeded, and then suddenly we get a lock error on the next module. We've carefully verified that, not only is this the only component using the .m2 directory at this time, but it's also the only Maven component being built on this system at this time.
We've experienced this issue sporadically since we upgraded from Java 8 to Java 21 last December (2024) and (in the process) we also upgraded from Maven 3.5.6 to 3.9.9 and from Artifactory to Nexus. We only just decided to file an issue on it because we've noticed that we're not seeing the lock issue if we downgrade to Maven 3.8.9, which I understand has a different locking mechanism. We've also noticed we do not see the issue when using Maven Daemon 1.0.1, though we do see an occasional daemon startup failure in 1.0.1 (different, unrelated issue).
We have also never seen the issue when using -T1 - this only occurs in multi-threaded builds (-T 1C).
Because it's sporadic, we never know when it's going to happen, so we don't have -e enabled during the build. If you need that data, we could temporarily enable it in our master builds, but it makes for some chatty logs.