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.

IRC, freenode, #hurd, 2013-07-29

<teythoon> about rpctrace, it poses as the kernel for its children, parses
  and relays any messages sent over the childrens message port, right?
<braunr> teythoon: rpctrace doesn't "poses as the kernel"
<braunr> well, it's close enough
<teythoon> but it intercepts messages send by its children by handing them
  a message port different from the one provided by the kernel, doesn't it?
<braunr> yes

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) ...

gnumach panic thread dispatch?

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 :)

IRC, freenode, #hurd, 2013-07-05

<pinotree> wish: make rpctrace decode the results of io_stat rpcs

IRC, freenode, #hurd, 2013-07-29

imho rpctrace is kind of a mess right now we should move the parsing code to a library that would also be useful for valgrind, it should have to do basically the same
IRC, freenode, #hurd, 2013-07-29

and I tried to rpctrace a subhurd, but rpctrace died on a assertion failure, some msg had an unexpected type or something rpctrace dies on select and guess what, the boot tool does call select on the console it emulates that's a shame, that'd be really useful for me it might not be hard to fix but i've never looked into it i only saw that rpctrace expects the common RPC message types and select is all but a common RPC so the type of the messages involved is slightly different and the assertion chokes on that rpctrace.c is huge and hand written, it'd be nice if the parser was created from the procedure definitions and thinking of that, mig does exactly that, one would only need some glue code select is partially hand written but it's a special case so that's ok
IRC, freenode, #hurd, 2013-12-11

teythoon: Congrats regarding rpctrace, is it now fully functional? should be well, you should be able to use it on any application that uses select other than that, it's as functional as it ever was i was annoyed that i couldn't rpctrace ping, and the fix was much easier than expected and fork is no problem anymore? was it ever ? yes, fork and some issues rpctrace should pick up any forked processes oh ? thanks for rpctrace too it was indeed on the todo list for a long time ah fork with regard to rpctrace no i don't think so but rpctrace can't be a perfect proxy because some calls just go directly through the kernel really ? we could install custom functions for any such call system calls yes so why couldn't it be perfect ? i don't see how custom functions would do the trick i mean it would help, but not guarantee applications have to use these functions the real solution would be something like strace huh ? why wouldn't there be any guarantee like that ? rpctrace catches messages, not system calls you don't see calls to mach_reply_port() obviously you just hope that such reply ports are sent through messages rpctrace will see http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html sure one does ah that we don't want that :p why not ? it's a hack and checking for those impacts performances a bit it would be better to change the system calls into RPCs so ? it would only affect tasks running in rpctrace, and the documentation does not call that interface a hack oh i agree i was saying we don't want them the same way we don't want async ipc yeah sure, i agree but since that's how mach works, why not although iirc, checking for emulated syscalls is done by the syscall entry code so ? so it has an impact on every system call we could make that a compile time option and use it in rpctrace only when available so anyone who needs good traces, could run that kind of kernel no need for what ? mach and the hurd are already too slow for this to be noticeable let's just live with it and use syscall emulation why do you say that, i mean, do you have numbers ? from what i see, it's a bunch of less than 5 instructions ok i'm just being picky i really don't like the idea of emulated system calls RPCs are much cleaner and frankly, the system calls that i'd like to see in rpctrace are those like mach_thread_self() to spot reference leaks not too annoying actually
IRC, freenode, #hurd, 2013-12-13

hm i briefly looked into the haskell test suite failure youpi wrote about i looked at one of the haskell-http-conduit failures i think it starts a dummy web server and does one request to itself the binary is using select, so i used the fixed rpctrace to obtain a trace it looks strange ... the http request is answered before the request is sent

teythoon: Nice to see that you added escape of non-printable characters in rpctrace:-D yeah, makes rpctrace less trippy though

IRC, OFTC, #debian-hurd, 2014-02-20

* pere really misses strace.
<pere> rpctrace is not even close.
<teythoon> pere: why do you say that ?
<teythoon> pere: it is not that we couldn't write strace for mach, it
  would just be very boring
<pere> teythoon: because strace tell me what a program does in details,
  without too much irrelevant information, while rpctrace is just so
  verbose that it is hard to see the relevant parts.
<youpi> well, they are mostly equivalent
<youpi> strace ls / gives me 200 lines, while rpctrace ls / gives me
  300 lines
<youpi> there are spurious lines like term_getctty, but otherwise it's
  mostly the same level of details
<youpi> (also, mach_port_deallocate get in the way)
<pere> strace also have the great advantage for C programmers that the
  output look like the equivalent C calls.
<youpi> well, twice as many lines is not so much more verbose :)
<youpi> but yes, having internal RPC names doesn't help
<youpi> another way would be to use sotruss
<pere> sotruss just gave me 'killed'
<youpi> yes, it probably needs fixing, nobody worked on it AFAIK
<youpi> that's why I said "would", not "is" :)
<pere> in the mean time, I'll just keep dreaming of something with
  output like strace. :)

IRC, freenode, #hurd, 2013-07-29

Issues and Patches

See Also