On Thu, 18 Dec 2025 15:05:24 GMT, Yasumasa Suenaga <[email protected]> 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
