On Sat, 27 Jun 2020 12:06:17 +0300 Andriy Gapon <avg_at_FreeBSD.org> wrote: > On 27/06/2020 10:44, Li-Wen Hsu wrote: > > On Sat, Jun 27, 2020 at 3:04 PM Hartmann, O. > > <ohartmann_at_walstatt.org> wrote: > >> > >> Running poudriere on recent CURRENT with (recent) 12-STABLE and > >> CURRENT jails reveals a weird behaviour recently when hitting > >> Ctrl-T: > > ... > >> Is this debug fallout from /bin/sh? > > > > It's because kern.tty_info_kstacks is on by default now: > > > > https://svnweb.freebsd.org/changeset/base/362141 > > May I suggest that the stack trace is printed procstat -kk style > (single line) ? I think that the more compact output would be more > convenient. It's a cool feature and having it on by default on CURRENT certainly helps to discover it, which is great. Thanks for implementing this! I wouldn't enable it by default on RELEASE versions though, as CTRL-T is a user interface to get status information (at least this is how I use it personally, e.g., while running commands like dd[0], cp, mv, poudriere etc.), not for getting debug output. Getting debug information every time I want to get the status seems like something that would make my user experience worse. I understand that this can be disabled locally, but that's a bit like changing the default syslog.conf to write messages of log level LOG_DEBUG to /var/log/messages. So, in the long run (before 13-RELEASE) I would prefer to disable it by default again, but maybe alter the default sysctl.conf to contain: # Uncomment this to show stack traces on SIGINFO (ctrl-t) #kern.tty_info_kstacks=1 Question: Speaking of discovering the feature, wouldn't it make sense to document this tunable on the stack(9) and/or tty(4) man page(s)? Just my 2 cents [0] Typical use case: $ dd if=/dev/random of=/dev/da0 bs=1m <presses CTRL-T> load: 0.37 cmd: dd 32247 [running] 0.91r 0.00u 0.88s 8% 2672k 149+0 records in 149+0 records out 156237824 bytes transferred in 0.922956 secs (169279818 bytes/sec) <presses CTRL-T again> load: 0.42 cmd: dd 32247 [running] 2.52r 0.00u 2.46s 21% 2676k 398+0 records in 398+0 records out 417333248 bytes transferred in 2.528253 secs (165067835 bytes/sec) ... -- Michael GmelinReceived on Sat Jun 27 2020 - 07:59:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC