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/?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
    

See Also

See also librpci.