On Tue, 30 Jun 2026 13:28:33 GMT, Coleen Phillimore <[email protected]> wrote:

>> Please review this change to allow XX configuration for specifying a 
>> different /tmp directory for the JVM to use.  In some container 
>> environments, /tmp and /proc/pid/root/tmp might not be usable and an 
>> alternate would be used.  This requires a release note and CSR.   Usage is:
>> 
>> java -XX:AltTempDir=/diags <app>
>> jps -J-XX:AltTempDir=/diags
>> jcmd -J-XX:AltTempDir=/diags <pid> <cmds>
>> 
>> Tested with a couple of tests and locally, and ran tier1-4.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Coleen Phillimore has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - Missed a ^M
>  - Fix whitespace characters and test.

There is a slight complication to the container attach:

I was first testing with a shared directory between host and container:

In container:
$ build/linux-x64/images/jdk/bin/java -XX:AltTempDir=/work App

on host:
$  build/linux-x64/images/jdk/bin/jcmd -J-XX:AltTempDir=/work
323811 jdk.jcmd/sun.tools.jcmd.JCmd
323651 App

...that's good.  /work is a shared directory.


For a host attaching to a process running in a container, where both are using 
AltTempDir, the tool on the host must of course specify the same AltTempDir, 
but that dir must also exist on the host.

Otherwise, the tool on the host gets:
[0.000s][warning][os] Warning: AltTempDir is ignored because it is not present 
or writable

So on the host, need to mkdir the AltTempDir, even though you don't really care 
about it.

We can avoid it by just not checking that AltTempDir exists, the 
is_writable_directory() call.
That works.

We can choose if we just don't check, or whether we warn but don't fail.
The jcmd on the host is not generally going to need its own tmp dir, just to 
know about the path the containerized process uses.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/31407#issuecomment-4844254682

Reply via email to