Quarkus boot fails when vertx-cache temporary directory exists
See original GitHub issueQuarkus boot fails when vertx-cache temporary directory exists. Running on Windows 10, using GraalVM 20 JDK 11 based, native image
2020-03-08 16:15:06,354 ERROR [io.qua.application] (main) Failed to start application: java.lang.IllegalStateException:
Failed to create cache dir: C:\Users\ROSTIS~1\AppData\Local\Temp\\vertx-cache/file-cache-9cf306ad-0c1b-4d8f-8468-f6d148da5859
First I thought the problem is in the file path which mixes Windows and Linux path separators, but that is not the problem.
The problem is that file-cache-9cf306ad-0c1b-4d8f-8468-f6d148da5859 directory exists and Quarkus native binary boot fails due to that fact. This directory was generated during mvn clean install -Dnative execution but wasn’t cleaned at the end.
Workaround is to remove that temporary directory and after this step Quarkus .exe app boots without problem, temporary directory gets cleaned during the shutdown. So following executions run without problem. The same file-cache directory gets generated on each run.
Few points:
- Vert.x code should handle the case when vertx-cache temporary directory exists
- Cleanup of the temporary dir doesn’t happen on
mvn clean install -Dnativeexecution - Temporary directory is resolved during the build time
The third point is the biggest issue from my perspective as it blocks portability (C:\Users\ROSTIS~1\AppData\Local\Temp\ would be expected on every system the app gets started?) I tried on another windows machine and the path is not fully hard-coded, user’s tmp directory is reflected, but the final directory is always file-cache-9cf306ad-0c1b-4d8f-8468-f6d148da5859,
Always the same path can be risky from a security perspective, knowledgeable users know where to look beforehand.
Steps to reproduce on sample bootstrap app:
mvn clean install -Dnative
target\getting-started-1.0-SNAPSHOT-runner.exe

Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:49 (45 by maintainers)
Top Related StackOverflow Question
The
vertx-cachedirectory should be world-writable, and it might not be the case. I need to investigate this.Another aspect that might be relevant: I’m running two instances of the same native runner on a machine on separate user accounts. The first one can be launched normally. The second one throws the same exception as above. The cause is that the first user has created and is thus owning
/tmp/vertx-cache. This makes the second process fail to write into the same path.Both users have defined the paths to separate temp dirs in the environment, e.g. for one of them:
I guess that the
/tmpbase path is either hard coded or taken from my development machine (or even from within the GraalVM container). So reading this value at runtime would be a benefit.For me the workaround using
-Djava.io.tmpdir=$TMPDIRhas helped.