From nobody Fri May 21 00:26:30 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 5442D8BDA35 for ; Fri, 21 May 2021 00:26:36 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmS8W6d3Kz3HBm; Fri, 21 May 2021 00:26:35 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 873027ef; Fri, 21 May 2021 00:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :cc:date:message-id:references:to; s=20180501; bh=BGcRto84Xs/Ev0 2g21xLD0IE6KE=; b=O18VKIwVyipdrk9tfjUPHfV+n3vZ7bueOJd/LRQa7VczUa ekl9k867epkT4zzapo0VQuN1eV6l69e9AzxHmCw/c7wOOWK5+/Wpu9kItFJ23PH2 zpQsp6tQIxY0fPDC6mF0ZL17HORNQEQxGLu+aULJJ230Rb97wN5llLIjoN/sW0Qt x1UtGk0A7am+XbcXIqtzaItqrA+V5ATP6ZiA3geFoCrlDRg518L0+IvxJaOddp4T hyFKU4qFBTm5PI9h274zlwZ7qeGMBgAk7gioqAezcxXZEL++nrDdkgpp/3Xpn6I6 QIWoqXppT1PPNBnBHQa4EC6ciPr94pG8jLy/FU3w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :cc:date:message-id:references:to; q=dns; s=20180501; b=n0bf3iuo FokbxuRolC9Y6mM05Sm8vG/ObVyFs8rZKZd0WLkEAW2tHjsdhqYPuDcy0msQ7Cvk ZKW012QBSsZ9trL8rpxrHhCwYQoLGa7NCrdhYYneqJuQZ6ivUlBir1fdzY7URPha LOCnnk66YXljtJVmpXLWM+4GOFBz+uNbXu1UdzHxN2+sfmEGs555Cl6naIKdAgZo an/S4uwNXfiQWsioXOLUSliei8DiTTEtT4i57PJe0LO7P4noNL5aIDVPrir5yEqH HPjg57IPBqLTSmEVAYYtNl10ZnewFyEcsq5dseGiYjrUjlSMlAFv2O00/Pqt1sa1 4MuZxbiKBJ5LHg== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5b50344a (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Fri, 21 May 2021 00:26:31 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-EDDD88C8-179E-4760-AE2D-C6450FB771C5 Content-Transfer-Encoding: 7bit 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 (1.0) Subject: Re: Reducing SIGINFO verbosity From: Michael Gmelin In-Reply-To: Cc: freebsd-current@freebsd.org Date: Fri, 21 May 2021 02:26:30 +0200 Message-Id: References: To: cem@freebsd.org X-Mailer: iPhone Mail (18E212) X-Rspamd-Queue-Id: 4FmS8W6d3Kz3HBm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes --Apple-Mail-EDDD88C8-179E-4760-AE2D-C6450FB771C5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 21. May 2021, at 01:00, Conrad Meyer wrote: > =EF=BB=BF > No, I don=E2=80=99t think there=E2=80=99s any reason to default it differe= ntly on stable vs current. I think it=E2=80=99s useful (and I prefer the mor= e verbose form, which isn=E2=80=99t the default). >=20 > Conrad=20 Well, to me siginfo is part of the user interface and changing the user inte= rface to show lots of debug information by default feels wrong (especially o= n a 80x25 terminal, where it now takes multiple lines). A typical example is= hitting ctrl-t a couple of times to see the progress in a long running dd o= peration, all the extra clutter makes this unnecessarily inconvenient. Maybe= your use case differs, I don=E2=80=99t need to see system call details when= checking the poudriere build status. In the end, personally this simply means that there is one more thing I have= to configure on every host in the future, I don=E2=80=99t really have the e= nergy to fight over this. It would be nice if changing defaults of things that were the same for decad= es would be mentioned somewhere in the release notes though. Or maybe in the= verbose output itself? Just an idea, how this could be done in a user frien= dly way: Right now we have=20 0 - normal 1 - verbose 2 - very verbose What about adding a bit here that controls an extra line saying: "You can control the verbosity of siginfo output with sysctl kern.tty_info_k= stacks" Therefore, we would have these additional values, one of them being the defa= ult value: 16 - normal + sysctl help message 17 - verbose + sysctl help message 18 - very verbose + sysctl message At this point the default won=E2=80=99t matter that much, as users learn abo= ut the feature after the update and can easily configure the setting that su= its their needs. Just trying to be somehow constructive here, having this on by default still= doesn=E2=80=99t feel right to me. Michael >=20 >> 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. >> >=20 >> > Traditionally, CTRL-t would give a one-line output + whatever the >> > process specific signal handler comes up with: >> >=20 >> > # 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 >> >=20 >> > # cat <--- hits CTRL-t >> > load: 0.02 cmd: cat 24379 [ttyin] 0.63r 0.00u 0.00s 0% 2308k >> >=20 >> > =20 >> > On 13 I get: >> >=20 >> > # 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 >> >=20 >> > # 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=20 >> >=20 >> > 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. >> >=20 >> > Setting >> >=20 >> > sysctl kern.tty_info_kstacks=3D0 >> > echo kern.tty_info_kstacks=3D0 >>/etc/sysctl.conf >> >=20 >> > fixes this permanently. >> >=20 >> > 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. >>=20 >> 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. >>=20 >> Conrad, >>=20 >> Should this be disabled on -stable now? >>=20 >> --=20 >> John-Mark Gurney Voice: +1 415 225 5579 >>=20 >> "All that I will do, has been done, All that I have, has not." --Apple-Mail-EDDD88C8-179E-4760-AE2D-C6450FB771C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 21. May 2021, at 01:00, C= onrad Meyer <cem@freebsd.org> wrote:

=EF=BB=BF
No, I don=E2=80= =99t think there=E2=80=99s any reason to default it differently on stable vs= current. I think it=E2=80=99s useful (and I prefer the more verbose form, w= hich isn=E2=80=99t the default).

Conrad 

Well, to me s= iginfo is part of the user interface and changing the user interface to show= lots of debug information by default feels wrong (especially on a 80x25 ter= minal, where it now takes multiple lines). A typical example is hitting ctrl= -t a couple of times to see the progress in a long running dd operation, all= the extra clutter makes this unnecessarily inconvenient. Maybe your use cas= e differs, I don=E2=80=99t need to see system call details when checking the= poudriere build status.

In the end, personally thi= s simply means that there is one more thing I have to configure on every hos= t in the future, I don=E2=80=99t really have the energy to fight over this.<= /div>

It would be nice if changing defaults of things tha= t were the same for decades would be mentioned somewhere in the release note= s though. Or maybe in the verbose output itself? Just an idea, how this coul= d be done in a user friendly way:

Right now we have=  
0 - normal
1 - verbose
2 - very verbose=

What about adding a bit here that controls an extr= a line saying:

"You can control the verbosity of si= ginfo output with sysctl kern.tty_info_kstacks"

The= refore, we would have these additional values, one of them being the default= value:

16 - normal + sysctl help message
17 - verbose + sysctl help message
18 - very verbose + sysctl mes= sage

At this point the default won=E2=80=99t matter= that much, as users learn about the feature after the update and can easily= configure the setting that suits their needs.

Just= trying to be somehow constructive here, having this on by default still doe= sn=E2=80=99t feel right to me.

Michael

On Thu, May 20, 2021 at 11:= 59 John-Mark Gurney <jmg@funkthat.com= > wrote:
Michael Gmelin wrote t= his message on Thu, May 20, 2021 at 18:01 +0200:
> I'm leaving this here, mostly so that others (or future me) can google<= br> > 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.00= s 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<= br> >   amd64_syscall+0x10c fast_syscall_common+0xf8 sleep: about 1= 19
>   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+0= x9
>   _cv_wait_sig+0xe4 tty_wait+0x1c ttydisc_read+0x2ac ttydev_r= ead+0x56
>   devfs_read_f+0xd5 dofileread+0x81 sys_read+0xbc amd64_sysca= ll+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=3D0
>   echo kern.tty_info_kstacks=3D0 >>/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<= br> for a developer, but not as helpful for most users.

Conrad,

Should this be disabled on -stable now?

--
  John-Mark Gurney              &nbs= p;               Voice: +1 415 225 5579
     "All that I will do, has been done, All that I have, has= not."
= --Apple-Mail-EDDD88C8-179E-4760-AE2D-C6450FB771C5--