Hide Forgot
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