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

IRC, freenode, #hurd, 2012-06-30

<mcsim> hello. Has anyone faced with problem when translator works
  fine, but when it is started via rpctrace it hangs? Probably you know
  what can cause this?
<antrik> mcsim: rpctrace itself is quite buggy
<antrik> zhengda once did a number of improvements, but they never went
  upstream...
<youpi> well, he never explained how his fixes worked :)
<youpi> GNU/Hurd is no different from other projects in that regard: if
  you don't explain how your patches work, there's low chance that they
  are applied
<youpi> unless the maintainer has time to dive himself, which we don't
<pinotree> "it compiles, ship it!"
<braunr> pinotree: i guess the hurd is different in that particular
  regard :p
<youpi> not different from linux
<braunr> eh, they include staging drivers now :)
<youpi> we have a sort-of staging tree as well, with netdde
<youpi> we don't really care about stability there
<antrik> youpi: actually, I think by now (and not to a small part
  because of this episode) that we are too strict about patch
  submission
<youpi> well, review really is needed, otherwise source gets into a bad
  shape
<antrik> while zhengda's variant might not have been ideal (nobody of
  us understands the workings of rpctrace enough to tell), I have
  little doubt that it would be an improvement...
<youpi> it happened quite a few times that a fix revealed to be
  actually bogus
<youpi> in that particular case, I agree
<youpi> the problem is that usually what happens is that questions are
  asked
<youpi> and the answers never happen
<youpi> and thus the patch gets lost
<antrik> after all, when he when he submitted that patch, he had a much
  better understanding of rpctrace than any of us...
<youpi> sure
<antrik> Linus is actually quite pragmatic about that. from what I've
  seen, if he can be convinced that something is *probably* an
  improvement over the previous status, he will usually merge it, even
  if he has some qualms
<youpi> when there is a maintainer, he usually requires his approval,
  doesn't he?
<antrik> in particular, for code that is new or has been in a very bad
  shape before, standards shouldn't be as high as for changes to known
  good code. and quite frankly, large parts of the Hurd code base
  aren't all that good to begin with...
<youpi> sure
<antrik> well, sure. in this case, we should have just appointed
  zhengda to be the rpctrace maintainer :-)
<antrik> BTW, as his version is quite fundamentally different, perhaps
  instead of merging the very large patch, perhaps we should just ship
  both versions, and perhaps drop the old one at some point if the new
  one turns out to work well...
<antrik> (and perhaps I overused the word perhaps in that sentence
  perhaps ;-) )
<youpi> about that particular patch, you had needed raised a few bits
<youpi> and there was no answers
<youpi> the patch is still in my mbox, far away
<youpi> so it was *not* technically lost
<youpi> it's just that as usual we lack manpower
<antrik> yeah, I know. but many of the things I raised were mostly
  formalisms, which might be helpful for maintaining high-quality code,
  but probably were just a waste of time and effort in this case... I'm
  not surprised that zhengda lost motivation to pursue this further :-(
<braunr> it would help a lot to get the ton of patches in the debian
  packages upstream :)
<youpi> braunr: there  aren't many, and usually for a good reason
<youpi> some of them are in debian for testing, and can probably be
  commited at some point
<pinotree> youpi: we could mark (with dep3 headers) the ones which are
  meant to be debian-specific
<youpi> sure
<antrik> well, there are also a few patches that are not exactly
  Debian-specific, but not ready for upstream either...
<youpi> antrik: yes

IRC, freenode, #hurd, 2012-07-18

<braunr> hm, rpctrace on gitk gives an interesting result
<braunr>   152<--153(pid1849)->io_set_all_openmodes_request (267) = 0 
<braunr> rpctrace:
  /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
  trace_and_forward: Assertion `reply_type == 18' failed.

This assertion is actually caused by using the io_select interface, which creates a send right instead of a send-once right for the reply port (IIRC).

IRC, OFTC, #debian-hurd, 2013-03-14

<youpi> uhu, there's a TODO just above that assertion :)

Issues and Patches

See Also