quarkus: Quarkus boot fails when vertx-cache temporary directory exists

Quarkus 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 -Dnative execution
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

Screenshot 2020-03-08 16 15 40

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 49 (45 by maintainers)

Commits related to this issue

Create /tmp/vertx-cache and configure it to be world-readable and writable. Under that directory, another random directory is created that is only readable and writable from the current user. The ver... — committed to cescoffier/quarkus by cescoffier 3 years ago

Most upvoted comments

The vertx-cache directory should be world-writable, and it might not be the case. I need to investigate this.

cescoffier on Feb 26, 2021

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:

# env | grep -i tmp
TEMPDIR=/tmp/user/107329
TMPDIR=/tmp/user/107329
TEMP=/tmp/user/107329
TMP=/tmp/user/107329

I guess that the /tmp base 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=$TMPDIR has helped.

thomas-mc-work on Feb 25, 2021

We were not able to reproduce. As if there were some specific permissions specified in the used OpenShift cluster. @pjgg was trying to reproduce this trouble.

rsvoboda on Feb 19, 2021

Windows native-image based binary generates always the same UUID.

I filed an issue in GraalVM tracker - https://github.com/oracle/graal/issues/2265

rsvoboda on Mar 17, 2020