On Wed, 28 Feb 2024 20:02:39 GMT, jdoylei <d...@openjdk.org> wrote: > If I understand the code change for this PR, I think it will change the > behavior in this scenario, because `findSocketFile` will have `pid == > ns_pid`, and now will use /tmp instead of `/proc/<pid>/root/tmp`, based on > `findTargetProcessTmpDirectory`. > > We are lucky currently that the only place the current OpenJDK 17 code checks > `pid == ns_pid` is the `createAttachFile` catch block that runs if > `/proc/<pid>/cwd/.attach_pid<ns_pid>` can't be created, since as long as > `/proc/<pid>/cwd` works, we are fine. But the `pid != ns_pid` check there > makes an assumption that if the process namespace is the same, the root > filesystem is the same and /tmp can be used, so this catch block wouldn't > work if we were to hit it in our scenario. I think propagating this catch > block logic into `findSocketFile` will break our scenario - it will force > using `/tmp/.java_pid<ns_pid>` and that won't work. > > Could the `findSocketFile` logic be made more robust to the different > namespace/filesystem scenarios? E.g. attempt `/proc/<pid>/root` first? Or > perhaps there is a way (not `pid != ns_pid`) to more accurately determine > whether / and `/proc/<pid>/root` are the same filesystem and /tmp is OK?
That is certainly worth capturing in a new JBS bug for investigating a further change. If you can't log one, I'll use the information here to do that, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1971364928
