Can't set the Jenkins /tmp dir via JAVA_OPTS and -Djava.io.tmpdir in a read only root file system setup.

[ericbrumfield]

Jenkins and plugins versions report

Environment

Using vanilla images from docker hub and attempting to run them as read only from cli. Systems I've attempted to do this from is a windows 10 machine that is running docker desktop. I have also attempted it from an AWS Fargate hosted context, specifying JAVA_OPTS that are ignored the same way.

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A as the container doesn't run in my test for this issue.

Reproduction steps

1. docker pull jenkins/jenkins:2.334-rhel-ubi8-jdk11
2. Extended the image from this one, exposed a directory and volume named /secondary that I wanted to use for tmp file use as I'll run this container instance as read only. Tagged it as jenkins_tmp_test:latest. The /secondary directory in this setup as chowned for jenkins:jenkins.
3. docker run -it --read-only --env JAVA_OPTS="-Djava.io.tmpdir=/secondary" -v E:/tmp/jenkins_tmp:/secondary jenkins_tmp_test:latest

Expected Results

That the container instance would run and use /secondary directory mount for tmpdir, allowing me to run the container instance with a read only root filesystem.

Actual Results

Container fails to run with the following error:

Running from: /usr/share/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
Exception in thread "main" java.io.IOException: Jenkins failed to create a temporary file in /tmp: java.io.IOException: Read-only file system
        at Main.extractFromJar(Main.java:405)
        at Main._main(Main.java:240)
        at Main.main(Main.java:108)
Caused by: java.io.IOException: Read-only file system
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createTempFile(File.java:2063)
        at Main.extractFromJar(Main.java:402)
        ... 2 more

Anything else?

I did attempt doing the same thing using jenkins/jenkins:latest, which does work correctly, so it seems that it is a bug somewhere in the ubi8 jdk11 container.