Use /proc/self instead of /proc/<pid> in getOpenedPath#1322
Conversation
|
@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this in D89913463. (Because this pull request was imported automatically, there will not be any future comments.) |
|
@ptarjan has updated the pull request. You must reimport the pull request before landing. |
ptarjan
force-pushed
the
claude/use-proc-self-soRMK
branch
from
47d6bdd to
d6a0213
Compare
|
@ptarjan has updated the pull request. You must reimport the pull request before landing. |
ptarjan
force-pushed
the
claude/use-proc-self-soRMK
branch
from
a78cbe5 to
d6a0213
Compare
I'm doing this to re-run the flaky test |
|
@ptarjan has updated the pull request. You must reimport the pull request before landing. |
1 similar comment
|
@ptarjan has updated the pull request. You must reimport the pull request before landing. |
ptarjan
force-pushed
the
claude/use-proc-self-soRMK
branch
from
47b33ef to
d6a0213
Compare
Simplify the procfs path construction by using /proc/self which is a symlink to the current process's directory, avoiding the need to call folly::get_cached_pid(). This also removes the now-unused Pid.h include.
ptarjan
force-pushed
the
claude/use-proc-self-soRMK
branch
from
d6a0213 to
aeb760a
Compare
|
@ptarjan has updated the pull request. You must reimport the pull request before landing. |
|
I'm giving up on CI. It is failing on |
|
@genevievehelsel is there anything else you need from me for this? |
nope! change looks good to me - just looking at getting some internal signal resolved today and getting this landed. Last week everyone was busy with yearly reviews, so didn't have the time 🙂 |
|
@genevievehelsel merged this pull request in ee956f5. |
Summary: When running in a PID namespace (common in containers), watchman fails with "need /proc to be mounted!" because it accesses /proc/<PID>/fd/X using the namespace PID, but /proc may be mounted from the host with different PID numbering. The fix is to use /proc/self/fd/X instead of /proc/<getpid()>/fd/X when resolving file descriptor paths. The /proc/self symlink is always resolved by the kernel to the current process's /proc entry, regardless of PID namespace boundaries. This issue manifests when: - Process is in a PID namespace (e.g., Docker container) - /proc is mounted from host or a different namespace - watchman tries to resolve paths via /proc/<PID>/fd Error seen: getOpenedPath: need /proc to be mounted!: Function not implemented Affected platforms: Linux containers with PID namespace isolation X-link: facebook/watchman#1322 Differential Revision: D89913463 Pulled By: genevievehelsel fbshipit-source-id: a855ca36309090276fe810a395a6637681b29249
|
No worries, thanks! |
3 participants
When running in a PID namespace (common in containers), watchman fails
with "need /proc to be mounted!" because it accesses /proc//fd/X
using the namespace PID, but /proc may be mounted from the host with
different PID numbering.
The fix is to use /proc/self/fd/X instead of /proc/<getpid()>/fd/X
when resolving file descriptor paths. The /proc/self symlink is always
resolved by the kernel to the current process's /proc entry, regardless
of PID namespace boundaries.
This issue manifests when:
Error seen:
getOpenedPath: need /proc to be mounted!: Function not implemented
Affected platforms: Linux containers with PID namespace isolation