RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v2]

[Sebastian Lövdahl]

On Thu, 18 Dec 2025 15:05:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected.
>> 
>> 
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>> 
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0,
>>    :
>> 
>> 
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory).
>> 
>> In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>> 
>> 
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded
>>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>>         at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>>         at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>>         at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>> 
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>> 
>> 
>> 
>> After this change, we can see following exception on the console of jcmd when we encounter this situation:
>> 
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>>         at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check whether target process is on same host

Curious how it works on your Fedora 43, I'm still seeing the same error.


[08:40:27] ~/d/e/jdk  pull/28867 ❯ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
52779:
com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:292)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:233)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:84)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
        at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
        at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
Caused by: java.nio.file.AccessDeniedException: /proc/52779/root/tmp
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
        at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
        at java.base/java.nio.file.Files.isSameFile(Files.java:1418)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:277)
        ... 6 more


It's the `Files.isSameFile(tmpOnProcPidRoot, TMPDIR)` check that throws `java.nio.file.AccessDeniedException`, so the `MonitoredHost.getMonitoredHost` check seems to come too late?

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 293:

> 291:         } catch (Exception e) {
> 292:             throw new AttachNotSupportedException("Unable to access the filesystem of the target process", e);
> 293:         }

Not sure if this stays like it is, but if it does, we can probably avoid wrapping `AttachNotSupportedException`:

Suggestion:

        } catch (AttachNotSupportedException e) {
            throw e;
        } catch (Exception e) {
            throw new AttachNotSupportedException("Unable to access the filesystem of the target process", e);
        }

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

PR Review: https://git.openjdk.org/jdk/pull/28867#pullrequestreview-3597133147
PR Review Comment: https://git.openjdk.org/jdk/pull/28867#discussion_r2633882957