Cause
Probing a user-space application requires a uprobes kernel module.
The --remote option used the path to the uprobes kernel module
for the client rather than proper path on the remote machine.
Consequence
If a uprobes module was not already loaded on the remote machine,
the instrumentation would not start and an error message like the following
would be printed:
ERROR: Unable to canonicalize path [...]: No such file or directory
Fix
Systemtap now properly communicates which uprobe module to load.
Result
User-space application probing will work properly with --remote option
even if uprobe kernel module not currently loaded on remote machine.
Description of problem:
When using --remote $HOST with a script that requires uprobes, systemtap will transfer uprobes.ko to be loaded on the remote. However, the command to run attempts to use a full path on the client, rather than somewhere on the remote.
Version-Release number of selected component (if applicable):
systemtap-1.6-1.el6
How reproducible:
100%
Steps to Reproduce:
1. Need two similar machines, $CLIENT and $REMOTE
2. On $REMOTE, rmmod uprobes if it's already loaded
3. Run stap from the $CLIENT, something that needs uprobes, e.g.
stap -e 'probe process.mark("*") { println(pn()) }' -c 'stap -l begin' \
--remote $REMOTE
Actual results:
ERROR: Unable to canonicalize path [...]: No such file or directory
(where [...] is a temp path on the $CLIENT)
Expected results:
Successful run, and uprobes will be loaded on the $REMOTE afterward.
Additional info:
I already fixed it upstream:
http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commit;h=18630fb81ed5433b31ae583694424cc0aed3123a
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
Probing a user-space application requires a uprobes kernel module.
The --remote option used the path to the uprobes kernel module
for the client rather than proper path on the remote machine.
Consequence
If a uprobes module was not already loaded on the remote machine,
the instrumentation would not start and an error message like the following
would be printed:
ERROR: Unable to canonicalize path [...]: No such file or directory
Fix
Systemtap now properly communicates which uprobe module to load.
Result
User-space application probing will work properly with --remote option
even if uprobe kernel module not currently loaded on remote machine.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1517.html
Description of problem: When using --remote $HOST with a script that requires uprobes, systemtap will transfer uprobes.ko to be loaded on the remote. However, the command to run attempts to use a full path on the client, rather than somewhere on the remote. Version-Release number of selected component (if applicable): systemtap-1.6-1.el6 How reproducible: 100% Steps to Reproduce: 1. Need two similar machines, $CLIENT and $REMOTE 2. On $REMOTE, rmmod uprobes if it's already loaded 3. Run stap from the $CLIENT, something that needs uprobes, e.g. stap -e 'probe process.mark("*") { println(pn()) }' -c 'stap -l begin' \ --remote $REMOTE Actual results: ERROR: Unable to canonicalize path [...]: No such file or directory (where [...] is a temp path on the $CLIENT) Expected results: Successful run, and uprobes will be loaded on the $REMOTE afterward. Additional info: I already fixed it upstream: http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commit;h=18630fb81ed5433b31ae583694424cc0aed3123a