Reducing SIGINFO verbosity

[Michael Gmelin]

Hi,

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.

Best
Michael

[0]https://cgit.freebsd.org/src/commit/sys/kern/tty_info.c?h=releng/13.0&id=508a6e84e785f642545b81c3ecb325685a2e56a7

[Alan Somers]

Post by Michael Gmelin
Hi,
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
# 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
# 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.
Best
Michael
[0]
https://cgit.freebsd.org/src/commit/sys/kern/tty_info.c?h=releng/13.0&id=508a6e84e785f642545b81c3ecb325685a2e56a7
--
Michael Gmelin

I tend to agree. I'm already using to using procstat to see a stuck
process's stacks, so I don't need to see them during ctrl-T, too.
-Alan

[Shawn Webb]

Post by Michael Gmelin
Hi,
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
# 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
# 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.

HardenedBSD also disables tty_info_kstacks by default given its
security ramifications. We're actively working to remove or mitigate
"kernel infoleak as features" we inherit from FreeBSD.

Thanks,

[Chris]

Post by Michael Gmelin
Hi,
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
# 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
# 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

YIKES!
Can you say POLA? ;-)

Post by Michael Gmelin
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

Thanks! :-)

Post by Michael Gmelin
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.

UPDATING?

Post by Michael Gmelin
Best
Michael

Thanks for mentioning it, Michael.

--Chris

Post by Michael Gmelin
[0]https://cgit.freebsd.org/src/commit/sys/kern/tty_info.c?h=releng/13.0&id=508a6e84e785f642545b81c3ecb325685a2e56a7

[John-Mark Gurney]

Post by Michael Gmelin
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
# 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
# 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?

[Conrad Meyer]

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

Post by John-Mark Gurney

Post by Michael Gmelin
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
# 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
# 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: [phone]
"All that I will do, has been done, All that I have, has not."

[Michael Gmelin]


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

Well, to me siginfo 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 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 operation, all the extra clutter makes this unnecessarily inconvenient. Maybe your use case differs, I don’t 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’t really have the energy to fight over this.

It would be nice if changing defaults of things that were the same for decades 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 friendly way:

Right now we have
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_kstacks"

Therefore, 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 message

At this point the default won’t 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 doesn’t feel right to me.

Michael

Post by John-Mark Gurney

Post by Michael Gmelin
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
# 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
# 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: [phone]
"All that I will do, has been done, All that I have, has not."

[Warner Losh]

Post by Conrad Meyer

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
Well, to me siginfo 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 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 operation, all the extra clutter makes this unnecessarily
inconvenient. Maybe your use case differs, I don’t 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’t really have the
energy to fight over this.
It would be nice if changing defaults of things that were the same for
decades 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
Right now we have
0 - normal
1 - verbose
2 - very verbose
"You can control the verbosity of siginfo output with sysctl
kern.tty_info_kstacks"
16 - normal + sysctl help message
17 - verbose + sysctl help message
18 - very verbose + sysctl message
At this point the default won’t 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 doesn’t feel right to me.

If this were a tunable, I think cem's default is good. We'll be able to get
more data than otherwise. Since the sysctl is writable, people can mostly
get the extra info by logging in elsewhere and setting it.

Part of me wants to have a toggle. Hit it 3 times in a second and we'd
toggle verbosity. But then we'd want to turn it off for security, so I'm
not so sure the complexity is worth it..

Warner


Michael

Post by Conrad Meyer

Post by John-Mark Gurney

Post by Michael Gmelin
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
# 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
# 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: [phone]
"All that I will do, has been done, All that I have, has not."

[Ian Lepore]

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.

-- Ian

Post by John-Mark Gurney

Post by Michael Gmelin
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
# 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
# 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: [phone]
"All that I will do, has been done, All that I have, has not."

[Peter Libassi]

Post by Ian Lepore

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.
— Ian

Well, from my 30+ years in the business I’ve learned that developers actually don’t care about the users. For assessment of new features and maintaining the usability of a product there are Architects and Architect forums.

The correct and conservative way would have been that this change passed the forum and there a desicion was made to enable/disable the new feature _and_ regardless, inform the users via the release notes and man pages of the new feature, including information how they can enable/disable the new feature.

/Peter

[Ceri Davies]

Post by Conrad Meyer
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).

I agree that there's no reason for the default to be different, but I
would say that it is much easier for someone who knows that there is a
default to be changed to change it, than it is for someone who does not.
Therefore, if the information is not useful to someone who does not know
how to get rid of it, then it should default to not being displayed,
IMHO.

Ceri

[Warner Losh]

Post by Ceri Davies

Post by Conrad Meyer
No, I don’t think there’s any reason to default it differently on stable

vs

Post by Conrad Meyer
current. I think it’s useful (and I prefer the more verbose form, which
isn’t the default).

I agree that there's no reason for the default to be different, but I
would say that it is much easier for someone who knows that there is a
default to be changed to change it, than it is for someone who does not.
Therefore, if the information is not useful to someone who does not know
how to get rid of it, then it should default to not being displayed,
IMHO.

I plan on changing the default for non-INVARIANT kernels back to
the old behavior.

INVARIANT kernels will keep this behavior because it's a debugging
kernel and this is one more thing to help debugging problems.

Warner

[Ceri Davies]

Post by Warner Losh

Post by Ceri Davies

Post by Conrad Meyer
No, I don’t think there’s any reason to default it differently on stable

vs

Post by Conrad Meyer
current. I think it’s useful (and I prefer the more verbose form, which
isn’t the default).

I agree that there's no reason for the default to be different, but I
would say that it is much easier for someone who knows that there is a
default to be changed to change it, than it is for someone who does not.
Therefore, if the information is not useful to someone who does not know
how to get rid of it, then it should default to not being displayed,
IMHO.

I plan on changing the default for non-INVARIANT kernels back to
the old behavior.
INVARIANT kernels will keep this behavior because it's a debugging
kernel and this is one more thing to help debugging problems.

Sounds good.

Ceri
--

[Alastair Hogge]

Post by Michael Gmelin
Hi,
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
# 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
# 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.

Thank you so much :-)

To good health,
Alastair

[Rodney W. Grimes]

Post by Ian Lepore

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...

Post by Ian Lepore
-- Ian

Michael Gmelin wrote this message on Thu, May 20, 2021 at 18:01

Post by Michael Gmelin
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
# 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
# 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."

[Rodney W. Grimes]

Post by Warner Losh

Post by Ceri Davies

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).

I agree that there's no reason for the default to be different, but I
would say that it is much easier for someone who knows that there is a
default to be changed to change it, than it is for someone who does not.
Therefore, if the information is not useful to someone who does not know
how to get rid of it, then it should default to not being displayed,
IMHO.

I plan on changing the default for non-INVARIANT kernels back to
the old behavior.
INVARIANT kernels will keep this behavior because it's a debugging
kernel and this is one more thing to help debugging problems.

This seems a good solution to me, thanks!

Post by Warner Losh
Warner