Bug 730167 - Wrong uprobes path attempted for remote systemtap
Summary: Wrong uprobes path attempted for remote systemtap
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Frank Ch. Eigler
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-12 01:12 UTC by Josh Stone
Modified: 2011-12-06 15:18 UTC (History)
4 users (show)

Fixed In Version: systemtap-1.6-2.el6
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2011-12-06 15:18:22 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1517 normal SHIPPED_LIVE systemtap bug fix and enhancement update 2011-12-06 00:50:46 UTC

Description Josh Stone 2011-08-12 01:12:41 UTC
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

Comment 4 William Cohen 2011-11-14 18:08:59 UTC
    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.

Comment 5 errata-xmlrpc 2011-12-06 15:18:22 UTC
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


Note You need to log in before you can comment on or make changes to this bug.