1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 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.
# Issues and Patches
[[!tag open_issue_hurd]]
* <http://savannah.gnu.org/patch/?2104> -- don't assert that local port names
are valid
* <http://savannah.gnu.org/bugs/?3939> -- `rpctrace`d program hangs when signal
that terminates or suspends it is sent
* <http://savannah.gnu.org/patch/?1633> -- terminated with `C-c` `rpctrace`d
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
[[!taglink 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 [[open_issues/librpci]].
|
