Date: Fri, 24 Mar 2017 13:50:39 -0700 From: John Baldwin <jhb@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt Message-ID: <2059536.bpqgJbnTOP@ralph.baldwin.cx> In-Reply-To: <20170324174509.GX23308@FreeBSD.org> References: <201703210639.v2L6dnRf055522@repo.freebsd.org> <2618830.hTJSphVT4p@ralph.baldwin.cx> <20170324174509.GX23308@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 24, 2017 10:45:09 AM Gleb Smirnoff wrote: > John, > > On Tue, Mar 21, 2017 at 02:24:30PM -0700, John Baldwin wrote: > J> > I have very much anticipated this comment from you, John. > J> > > J> > I would like to remind you, that we have had this very exact conversation > J> > back when I removed kvm support from netstat/route.c. Let me search the > J> > archives: > J> > > J> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html > J> > > J> > This conversation has had a continuation on IRC, which I don't archive. > J> > > J> > AFAIR, first I told that with all my involvement into networking stack, > J> > I never ever had experienced a need to run route stats on a core. The > J> > debugger were the only useful tool. And that opinion was seconded by > J> > other network hackers. Then we discussed that a proper tool chould use > J> > dynamic type parsing and not kvm(3). You said that future gdb has python > J> > scripting and that would work fine. Meanwhile, you insisted that I restore > J> > the functionality. I resisted to put kvm(3) back into netstat/route.c, and > J> > instead I created a gdb script that prints exactly what 'nestat -anr -M core' > J> > prints. And I committed the script just to satisfy your demand: > J> > > J> > tools/debugscripts/netstat-anr.gdb > J> > > J> > Can you please fairly answer, have you (or anyone else) ever used the > J> > script during these 2 years? > J> > J> You never updated crashinfo to use the script (the point of crashinfo is to > J> give an automated bit of information users can include in bug reports). > J> crashinfo came from Yahoo! where knowing the active state of the system > J> during a crash was indeed useful. It wasn't necessarily about debugging a > J> panic in the network stack, but about obtaining information about the system > J> useful in debugging crashes in arbitrary parts of the kernel. I don't work > J> at Y! anymore, so I'm not in the same environment. Those things tend to be > J> more useful when dealing with a large deployment of hetergenous systems > J> rather than doing focused development on a driver or a bunch of identical > J> systems with the same workload / role (e.g. appliances). > > Since you outlined that it is important that systems are heterogenous, looks > like you anticipated my reply that at Netflix we also do automated crash > collection. :) > > Still, my personal experience is that when analyzing a crash, you aren't > interested in full table, be it a routing table or a PCB list. You are > focused on the entry that crashed. This experience comes from my previous > job Rambler, which is a Russian version of Yahoo! :) > All the time I analyzed our internal crashes, or FreeBSD PRs, I always > PgDown-ed this tons of information. I'm not saying it is always useful, but it is sometimes useful. And it may not be a panic in the network stack, but more "which connections and on which mix of ports were active when it crashed". 'ps' output isn't only useful when you have a crash in fork(). It happens to be useful for other types of panics as well. > J> Also, the setgid thing is a red herring. You don't need setgid to read from > J> a core, only to use kvm against a live system. I'm all for using sysctls to > J> fetch data against live system and only keeping kvm for use with core dumps > J> which doesn't require setgid. > > Which means that if you want a tool to print out stats from a core, that should > be a separate tool. And the runtime tool netstat should get free of kvm, and of > setgid bit. A separate tool means that you have to reproduce the formatting bits, and it is convenient to have consistent output. > Here we again come to the need of debugger with better scripting support. What > are the expectations for newer gdb which has python scripting? 'pkg install gdb' has provided a working kgdb for over a year now. crashinfo will even look for and prefer kgdb from ports over kgdb from base. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2059536.bpqgJbnTOP>