Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jun 2017 17:15:41 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Gleb Smirnoff <glebius@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r319874 - head/sys/kern
Message-ID:  <20170615141540.GT2088@kib.kiev.ua>
In-Reply-To: <20170615050400.GP50023@FreeBSD.org>
References:  <201706122111.v5CLBBUT092606@repo.freebsd.org> <20170612234356.GD50023@FreeBSD.org> <20170613120643.GX2088@kib.kiev.ua> <20170615050400.GP50023@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 14, 2017 at 10:04:00PM -0700, Gleb Smirnoff wrote:
> On Tue, Jun 13, 2017 at 03:06:43PM +0300, Konstantin Belousov wrote:
> K> On Mon, Jun 12, 2017 at 04:43:56PM -0700, Gleb Smirnoff wrote:
> K> > On Mon, Jun 12, 2017 at 09:11:11PM +0000, Konstantin Belousov wrote:
> K> > K> Author: kib
> K> > K> Date: Mon Jun 12 21:11:11 2017
> K> > K> New Revision: 319874
> K> > K> URL: https://svnweb.freebsd.org/changeset/base/319874
> K> > K> 
> K> > K> Log:
> K> > K>   Print unimplemented syscall number to the ctty on SIGSYS, if enabled
> K> > K>   by the knob kern.lognosys.
> K> > 
> K> > Why is it off by default?
> K> In some (non-default) situation it may cause lot of ctty output.
> K> I made the knob tunable to allow it to be set very early (init)
> K> if needed.
> 
> I remember myself being a beginner UNIX user, and all this
> "bad system call, core dumped" messages were so annoyingly
> uninformative for me, and I had no idea how to track to the
> actual problem. This feature gives a lot of clue for a beginner
> user, but having it default to off, devaluates its value.
> 
> To avoid possible tty spam for an application that produces ton
> of bad syscalls, but ignores SIGSYS, we can enable the feature
> for those processes, who doesn't ignore SIGSYS.
I am curious how would you define the process or thread state which
ignores SIGSYS. The signal can be ignored or blocked in the signal mask,
or catched. All these dispositions cause controlling terminal spam.

Also, I do no see a good solution for rate-limiting the message. I argue
that rate-limiting must be per-process or even per-thread and not system
global, but I do not want to add even an int field to struct thread for
this.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170615141540.GT2088>