On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin <l...@altlinux.org> wrote: > On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote: >> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin <l...@altlinux.org> wrote: >> >> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e. >> > print their addresses in <> form, resembling lsof(8) output. This would >> > be a really nice feature. >> >> Indeed that would be awesome and help a lot with tracing network related >> calls. >> >> I think you meant this lsof output, for instance from a wget invocation: >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> wget 3695865 pombredanne 3u IPv4 125707086 0t0 TCP >> myhost.local:56120->ch3.sourceforge.net:http (ESTABLISHED) >> >> How would you report this? >> >> Would this work for the example above?: >> 3<socket:[125707086] IPv4, TCP, "myhost.local:56120", >> "ch3.sourceforge.net:http"> >> where: >> - IPv4 would be the type as reported by lsof(8) >> - TCP, "myhost.local:56120" and "ch3.sourceforge.net:http" would the >> parts of the node name as reported by lsof(8) > > Employing network address resolving in strace is risky because of > potentially huge delays it may cause. > By mentioning "lsof" I rather meant "lsof -n".
Good point, lsof-like reverse DNS lookup kind of call would be a killer and fragile too. I always wondered why this is a default for lsof btw > The exact output format may vary, but the general idea of strace decoding > is to mimic C syntax. From this PoV, path names should always be enclosed > in double quotes. Unfortunately, in case of -y output this rule hasn't > been enforced, so you cannot distinguish a socket with inode 1234567 with > a file named "socket:[1234567]". The someone naming a file "socket:[1234567]" ought to get at least a good slap on the wrist :D On the other hand, this could be a mistake and one that strace could help debug and find Now could this be something that could be fixed as part of advanced path decoding? or is it really worth adding quotes around all decoded "real" paths to care for such a rare case? -- Philippe Ombredanne On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin <l...@altlinux.org> wrote: > On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote: >> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin <l...@altlinux.org> wrote: >> >> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e. >> > print their addresses in <> form, resembling lsof(8) output. This would >> > be a really nice feature. >> >> Indeed that would be awesome and help a lot with tracing network related >> calls. >> >> I think you meant this lsof output, for instance from a wget invocation: >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> wget 3695865 pombredanne 3u IPv4 125707086 0t0 TCP >> myhost.local:56120->ch3.sourceforge.net:http (ESTABLISHED) >> >> How would you report this? >> >> Would this work for the example above?: >> 3<socket:[125707086] IPv4, TCP, "myhost.local:56120", >> "ch3.sourceforge.net:http"> >> where: >> - IPv4 would be the type as reported by lsof(8) >> - TCP, "myhost.local:56120" and "ch3.sourceforge.net:http" would the >> parts of the node name as reported by lsof(8) > > Employing network address resolving in strace is risky because of > potentially huge delays it may cause. > By mentioning "lsof" I rather meant "lsof -n". > > The exact output format may vary, but the general idea of strace decoding > is to mimic C syntax. From this PoV, path names should always be enclosed > in double quotes. Unfortunately, in case of -y output this rule hasn't > been enforced, so you cannot distinguish a socket with inode 1234567 with > a file named "socket:[1234567]". > > > -- > ldv > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Strace-devel mailing list > Strace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/strace-devel > -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 799 0949. ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
