rpctrace is -- roughly -- an equivavlent to Linux's strace or Solaris' or BSD's truss. It is used to trace remote procedure calls a process is doing.

See rpctrace --help about how to use it.

Issues and Patches

http://savannah.gnu.org/patch/?2104 -- don't assert that local port names are valid
http://savannah.gnu.org/bugs/?3939 -- rpctraced program hangs when signal that terminates or suspends it is sent
- http://savannah.gnu.org/patch/?1633 -- terminated with C-c rpctraced programs hang
http://savannah.gnu.org/patch/?5580 -- more readable output

IRC, unknown channel, unknown date

<youpi> how to rpctrace a translator ?
<youpi> ah, just settrans /usr/bin/rpctrace...
<youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected
  state) ...

IRC, unknown channel, unknown date

<antrik> hm... for a funny effect, try running rpctrace on
  /servers/socket/1, and then use dpkg... ;-)

IRC, unknown channel, unknown date.

<youpi> the problem of rpctrace is that it's a man in the middle :)
<youpi> so in principle, by design authentication stuff shouldn't work
<antrik> I don't think the Hurd auth mechanism in any way prevents or tries to prevent man-in-the-middle...
<youpi> maybe, but just try, you'll see all kinds of issue as soon as you have authentication stuff
<youpi> and the basic reason is that being a man in the middle needs special care
<youpi> which rpctrace doesn't completely do
<antrik> it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly
<antrik> 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
<antrik> 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

open issue documentation

<mcsim> hello. Are there any documentation about understanding output
  of rpctrace?
<braunr> no
<braunr> you should read the source code, best doc available
<braunr> if you have too many numbers and almost no symbolc names,
  you're lacking rpc definition lists
<braunr> check that the gnumach-common package is installed, as it
  provides the gnumach definitions
<braunr> (the glibc ones are almost always available)
<braunr> with those two, you should be fine for the beginning
<mcsim> gnumach-common is installed. And what is the name for glibc
  package for gnumach definitions.
<mcsim> Also I'm using libraries specified by LD_LIBRARY_PATH. Does it
  make influence on absence of symbolic names?
<braunr> no
<braunr> rpctrace --help
<braunr> see the --rpc-list=FILE option
<braunr> the default lists are in /usr/share/msgids/, with the .msgids
  extension
<braunr> $ dpkg -S msgids
<braunr> gnumach-common: /usr/share/msgids/gnumach.msgids
<braunr> hurd: /usr/share/msgids/hurd.msgids
<braunr> ok, glibc has none, it's the hurd
<braunr> for more details about the output, read the source code
<braunr> it shouldn't be that hard to grasp
<mcsim> -I /usr/share/msgids helped
<mcsim> thank you
<braunr> it shouldn't have, it's the default path
<mcsim> but symbolic names appeared
<braunr> well, that's weird :)
<pinotree> braunr: the output of rpctrace --help should tell the
  default dir for msgids

Issues and Patches

See Also