From nobody Fri May 21 11:39:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9CE0B8C2C03 for ; Fri, 21 May 2021 11:39:35 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fml532PFHz4tvp; Fri, 21 May 2021 11:39:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 14LBdQY7012697; Fri, 21 May 2021 04:39:26 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 14LBdQLR012696; Fri, 21 May 2021 04:39:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202105211139.14LBdQLR012696@gndrsh.dnsmgr.net> Subject: Re: Reducing SIGINFO verbosity In-Reply-To: <80625b01dd7a2740a23c22370741665e5d2ff6e5.camel@freebsd.org> To: Ian Lepore Date: Fri, 21 May 2021 04:39:26 -0700 (PDT) CC: cem@FreeBSD.org, Michael Gmelin , "freebsd-current@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4Fml532PFHz4tvp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] > On Thu, 2021-05-20 at 15:57 -0700, Conrad Meyer wrote: > > No, I don?t think there?s any reason to default it differently on > > stable vs > > current. I think it?s useful (and I prefer the more verbose form, > > which > > isn?t the default). > > > > Conrad > > > > So... there are thousands of freebsd users, who don't care about this > noisy stack trace stuff at all. And there are dozens of freebsd > developers, and amongst them there are maybe, what... a half dozen at > best that want this info when they hit ^T? > > So clearly, the right decision is to make maximal noise the default, > and not just in the development branches. It doesn't matter how much > it bothers the users as long as a few developers are happy. > > And people moan about freebsd's dwindling user base and wonder why it's > withering away. > I'll add my $1.00 to the dog pile. Ian is 1000% correct here, as a person who often interacts with the "non-developer" userbase they do not like, nor appreciate these "developer friendly" changes that make using the system annoying to them. You may say the project is not getting feedback about this... let me cover that too.. the feedback is silent, they simply move to another platform that is more conformant with how they expect/want the system to behave. A lot of people see me pushing back on things often and think it is just me being a really quirky user, well yes, to some extent, but I am a "user" first, and a developer second, and I interact a great deal with the "users" of freeBSD, far more than I do with the developers. LIttle changes is all it takes to annoy them enough they simply go some place else... colourised ls that suddenly showed up landed me at least 4 people going "wtf". Change to more/less behavior got me a few as well, it was like ":why?" The less people just simply set it in 2 /etc files and the system can switch back and forth, but now WHO has to make that setting tweak has changed... It is the death of a 1M pin pricks... please stop the bleeding... > -- Ian > > > On Thu, May 20, 2021 at 11:59 John-Mark Gurney > > wrote: > > > > > Michael Gmelin wrote this message on Thu, May 20, 2021 at 18:01 > > > +0200: > > > > I'm leaving this here, mostly so that others (or future me) can > > > > google > > > > it up. > > > > > > > > Traditionally, CTRL-t would give a one-line output + whatever the > > > > process specific signal handler comes up with: > > > > > > > > # sleep 120 <--- hits CTRL-t > > > > load: 0.27 cmd: sleep 38162 [nanslp] 0.64r 0.00u 0.00s 0% > > > > 1780k > > > > sleep: about 119 second(s) left out of the original 120 > > > > > > > > # cat <--- hits CTRL-t > > > > load: 0.02 cmd: cat 24379 [ttyin] 0.63r 0.00u 0.00s 0% 2308k > > > > > > > > > > > > On 13 I get: > > > > > > > > # sleep 120 <--- hits CTRL-t > > > > load: 0.12 cmd: sleep 3241 [nanslp] 0.52r 0.00u 0.00s 0% 2172k > > > > mi_switch+0xc1 sleepq_catch_signals+0x2e6 > > > > sleepq_timedwait_sig+0x12 > > > > _sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b > > > > amd64_syscall+0x10c fast_syscall_common+0xf8 sleep: about 119 > > > > second(s) left out of the original 120 > > > > > > > > # cat <--- hits CTRL-t > > > > load: 0.09 cmd: cat 3240 [ttyin] 0.23r 0.00u 0.00s 0% 2300k > > > > mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 > > > > _cv_wait_sig+0xe4 tty_wait+0x1c ttydisc_read+0x2ac > > > > ttydev_read+0x56 > > > > devfs_read_f+0xd5 dofileread+0x81 sys_read+0xbc > > > > amd64_syscall+0x10c > > > > fast_syscall_common+0xf8 > > > > > > > > which is quite way too verbose when checking the progress of > > > > long-running processes, like cp, dd, or poudriere. Especially as > > > > CTRL-t > > > > is part of the user experience to me - I use it to interact with > > > > the > > > > machine outside of debugging software issues. > > > > > > > > Setting > > > > > > > > sysctl kern.tty_info_kstacks=0 > > > > echo kern.tty_info_kstacks=0 >>/etc/sysctl.conf > > > > > > > > fixes this permanently. > > > > > > > > Apparently, this was enabled by default on purpose[0], so that > > > > people > > > > find the feature (which certainly worked ^_^), but I think it > > > > would > > > > been worth mentioning the sysctl somewhere in the release > > > > notes/errata, > > > > so that people understand how to disable it again. > > > > > > I think the original intent was to disable this on -stable or at > > > least > > > -RELEASEs, but it looks like this didn't happen. This is VERY > > > helpful > > > for a developer, but not as helpful for most users. > > > > > > Conrad, > > > > > > Should this be disabled on -stable now? > > > > > > -- > > > John-Mark Gurney Voice: +1 415 225 > > > 5579 > > > > > > "All that I will do, has been done, All that I have, has not." > > > > > > -- Rod Grimes rgrimes@freebsd.org