Use /proc/pid/exe for the Python binary in Linux #364
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of "/proc/pid/root/$(readlink /proc/pid/exe)", we'll just use /proc/pid/exe which provides access to the file even if it was deleted on-disk. This is not uncommon - for example, Python may be upgraded and thus long-running processes no longer have the correct file at the specified path. After this change we can profile/dump those processes (only if they are Python-binary based and not libpython-based; the latter is inaccessible if deleted... perhaps only partially accessible via /proc/pid/map_files).
Jongy
commented
Mar 20, 2021
benfred
approved these changes
Mar 21, 2021
benfred
reviewed
Mar 21, 2021
|
@benfred note that we need to bump the version of |
Jongy
added a commit
to Granulate/gprofiler
that referenced
this pull request
May 1, 2021
There's no need to move the the target PID namespace.
The link can be passed to execve itself. It has the benefit of running even if
the file was deleted (for example - if the Java installation was upgraded then
readlink("/proc/pid/exe") returns the path with " (deleted)", but executing
/proc/pid/exe will run the "old" version just fine (as long as all libs exist, etc).
This matches the fix I posted for py-spy: benfred/py-spy#364
Jongy
added a commit
to Granulate/gprofiler
that referenced
this pull request
May 2, 2021
There's no need to move the the target PID namespace.
The link can be passed to execve itself. It has the benefit of running even if
the file was deleted (for example - if the Java installation was upgraded then
readlink("/proc/pid/exe") returns the path with " (deleted)", but executing
/proc/pid/exe will run the "old" version just fine (as long as all libs exist, etc).
This matches the fix I posted for py-spy: benfred/py-spy#364
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of "/proc/pid/root/$(readlink /proc/pid/exe)", we'll just use /proc/pid/exe
which provides access to the file even if it was deleted on-disk.
This is not uncommon - for example, Python may be upgraded and thus long-running
processes no longer have the correct file at the specified path.
After this change we can profile/dump those processes (only if they are Python-binary
based and not libpython-based; the latter is inaccessible if deleted... perhaps only
partially accessible via /proc/pid/map_files).
Note: this depends on rbspy/proc-maps#8 because currently we don't extract the full filename from
/proc/pid/maps, so the comparison inis_python_bin(matchingreadlink("/proc/pid/exe")to filenames in/proc/pid/maps) always fails.With this PR (and the
proc-mapsfix) I managed topy-spy dumpPython processes that were started before I upgraded Python on my local box :) (so they now run/usr/bin/python3.8 (deleted))