[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] *rpctrace* is -- roughly -- an equivavlent to Linux's *strace* or Solaris' or BSD's *truss*. It is used to trace [[remote_procedure_call|rpc]]s a process is doing. See `rpctrace --help` about how to use it. # Issues and Patches [[!tag open_issue_hurd]] * -- don't assert that local port names are valid * -- `rpctrace`d program hangs when signal that terminates or suspends it is sent * -- terminated with `C-c` `rpctrace`d programs hang * -- more readable output * IRC, unknown channel, unknown date how to rpctrace a translator ? ah, just settrans /usr/bin/rpctrace... hum, it hung, and killing it got a Mach panic (thread in unexpected state) ... * IRC, unknown channel, unknown date hm... for a funny effect, try running rpctrace on /servers/socket/1, and then use dpkg... ;-) * IRC, unknown channel, unknown date. the problem of rpctrace is that it's a man in the middle :) so in principle, by design authentication stuff shouldn't work I don't think the Hurd auth mechanism in any way prevents or tries to prevent man-in-the-middle... maybe, but just try, you'll see all kinds of issue as soon as you have authentication stuff and the basic reason is that being a man in the middle needs special care which rpctrace doesn't completely do it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these... * IRC, freenode, #hurd, 2011-11-04 [[!taglink open_issue_documentation]] hello. Are there any documentation about understanding output of rpctrace? no you should read the source code, best doc available if you have too many numbers and almost no symbolc names, you're lacking rpc definition lists check that the gnumach-common package is installed, as it provides the gnumach definitions (the glibc ones are almost always available) with those two, you should be fine for the beginning gnumach-common is installed. And what is the name for glibc package for gnumach definitions. Also I'm using libraries specified by LD_LIBRARY_PATH. Does it make influence on absence of symbolic names? no rpctrace --help see the --rpc-list=FILE option the default lists are in /usr/share/msgids/, with the .msgids extension $ dpkg -S msgids gnumach-common: /usr/share/msgids/gnumach.msgids hurd: /usr/share/msgids/hurd.msgids ok, glibc has none, it's the hurd for more details about the output, read the source code it shouldn't be that hard to grasp -I /usr/share/msgids helped thank you it shouldn't have, it's the default path but symbolic names appeared well, that's weird :) braunr: the output of rpctrace --help should tell the default dir for msgids # See Also See also [[open_issues/librpci]].