[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 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. # IRC, freenode, #hurd, 2013-07-29 about rpctrace, it poses as the kernel for its children, parses and relays any messages sent over the childrens message port, right? teythoon: rpctrace doesn't "poses as the kernel" well, it's close enough 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? yes # 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) ... [[open_issues/gnumach_panic_thread_dispatch]]? * 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 * IRC, freenode, #hurd, 2012-06-30 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? mcsim: rpctrace itself is quite buggy zhengda once did a number of improvements, but they never went upstream... well, he never explained how his fixes worked :) 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 unless the maintainer has time to dive himself, which we don't "it compiles, ship it!" pinotree: i guess the hurd is different in that particular regard :p not different from linux eh, they include staging drivers now :) we have a sort-of staging tree as well, with netdde we don't really care about stability there youpi: actually, I think by now (and not to a small part because of this episode) that we are too strict about patch submission well, review really is needed, otherwise source gets into a bad shape 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... it happened quite a few times that a fix revealed to be actually bogus in that particular case, I agree the problem is that usually what happens is that questions are asked and the answers never happen and thus the patch gets lost after all, when he when he submitted that patch, he had a much better understanding of rpctrace than any of us... sure 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 when there is a maintainer, he usually requires his approval, doesn't he? 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... sure well, sure. in this case, we should have just appointed zhengda to be the rpctrace maintainer :-) 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... (and perhaps I overused the word perhaps in that sentence perhaps ;-) ) about that particular patch, you had needed raised a few bits and there was no answers the patch is still in my mbox, far away so it was *not* technically lost it's just that as usual we lack manpower 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 :-( it would help a lot to get the ton of patches in the debian packages upstream :) braunr: there aren't many, and usually for a good reason some of them are in debian for testing, and can probably be commited at some point youpi: we could mark (with dep3 headers) the ones which are meant to be debian-specific sure well, there are also a few patches that are not exactly Debian-specific, but not ready for upstream either... antrik: yes * IRC, freenode, #hurd, 2012-07-18 hm, rpctrace on gitk gives an interesting result 152<--153(pid1849)->io_set_all_openmodes_request (267) = 0 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 uhu, there's a TODO just above that assertion :) * IRC, freenode, #hurd, 2013-07-05 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. rpctrace is not even close. pere: why do you say that ? pere: it is not that we couldn't write strace for mach, it would just be very boring 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. well, they are mostly equivalent strace ls / gives me 200 lines, while rpctrace ls / gives me 300 lines there are spurious lines like term_getctty, but otherwise it's mostly the same level of details (also, mach_port_deallocate get in the way) strace also have the great advantage for C programmers that the output look like the equivalent C calls. well, twice as many lines is not so much more verbose :) but yes, having internal RPC names doesn't help another way would be to use sotruss sotruss just gave me 'killed' yes, it probably needs fixing, nobody worked on it AFAIK that's why I said "would", not "is" :) in the mean time, I'll just keep dreaming of something with output like strace. :) # See Also See also [[open_issues/librpci]].