From owner-svn-src-head@freebsd.org Fri Mar 24 20:50:56 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 513F5D1B34C; Fri, 24 Mar 2017 20:50:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BF711169; Fri, 24 Mar 2017 20:50:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id A09BA10A7B9; Fri, 24 Mar 2017 16:50:54 -0400 (EDT) From: John Baldwin To: Gleb Smirnoff 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 Date: Fri, 24 Mar 2017 13:50:39 -0700 Message-ID: <2059536.bpqgJbnTOP@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170324174509.GX23308@FreeBSD.org> References: <201703210639.v2L6dnRf055522@repo.freebsd.org> <2618830.hTJSphVT4p@ralph.baldwin.cx> <20170324174509.GX23308@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 24 Mar 2017 16:50:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:50:56 -0000 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