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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 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
<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
[[!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
* 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
<teythoon> imho rpctrace is kind of a mess right now :-/ we should move the
parsing code to a library
<teythoon> that would also be useful for valgrind, it should have to do
basically the same
* IRC, freenode, #hurd, 2013-07-29
<teythoon> and I tried to rpctrace a subhurd, but rpctrace died on a
assertion failure, some msg had an unexpected type or something
<braunr> rpctrace dies on select
<braunr> and guess what, the boot tool does call select on the console it
emulates
<teythoon> that's a shame, that'd be really useful for me
<braunr> it might not be hard to fix
<braunr> but i've never looked into it :/
<braunr> i only saw that rpctrace expects the common RPC message types
<braunr> and select is all but a common RPC
<braunr> so the type of the messages involved is slightly different
<braunr> and the assertion chokes on that
<teythoon> rpctrace.c is huge and hand written, it'd be nice if the parser
was created from the procedure definitions
<teythoon> and thinking of that, mig does exactly that, one would only need
some glue code
<braunr> select is partially hand written
<braunr> but it's a special case so that's ok
# See Also
See also [[open_issues/librpci]].
|
