Better tracing of network calls [was Re: GSOC candidature draft for urgent feedback]

[Philippe Ombredanne]

On Mon, Mar 3, 2014 at 10:15 PM, enh <enh at google.com> wrote:
> On Sun, Mar 2, 2014 at 3:39 AM, Philippe Ombredanne
> <pombredanne at nexb.com> wrote:
>> On Tue, Feb 25, 2014 at 8:49 PM, enh <enh at google.com> wrote:
[...]
>> On the pipes side, I am a bit more puzzled as what more could be done....
>>
>> pipe(2) has nothing we could decode afaik?
>>
>> Are you talking about decoding more of dup(2) dup2/3 and fcntl(2) with
>> F_DUPFD  when there is a pipe involved?
>>
>> I think that for pipes the only thing that can be done on a per
>> syscall is to have a the pipe fd... and that tracing what went into
>> the pipe is only something that can be done by reasoning not on a
>> single syscall but across multiple calls and eventually multiple
>> processes, in effect parsing a whole strace output, or is there
>> something you think could be done at the syscall level?
>
> what i've done in the past is match the ids across processes to see
> what process is on the other end. i don't know of any better way to do
> this that go through all of /proc. i suppose strace could model fd
> inheritance, but it all sounds hard and not worth the trouble. (i've
> had to do this probably twice in the last decade!) i was just throwing
> it out there.

Makes sense. I actually wrote a rather ugly piece of code to
post-process a -tttff strace output and track files, pipes and sockets
IOs across calls and processes.
IMHO the best would be to wait a bit when we have a structure output
and have a few example scripts that can do such whole trace analysis,
the most interesting areas to me being files/descriptors, pipes and
sockets operations.

-- 
Philippe Ombredanne