From: Walt Drummond <walt@drummond.us>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
aacraid@microsemi.com, viro@zeniv.linux.org.uk,
anna.schumaker@netapp.com, arnd@arndb.de, bsegall@google.com,
bp@alien8.de, chuck.lever@oracle.com, bristot@redhat.com,
dave.hansen@linux.intel.com, dwmw2@infradead.org,
dietmar.eggemann@arm.com, dinguyen@kernel.org,
geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com,
idryomov@gmail.com, mingo@redhat.com, yzaikin@google.com,
ink@jurassic.park.msu.ru, jejb@linux.ibm.com, jmorris@namei.org,
bfields@fieldses.org, jlayton@kernel.org, jirislaby@kernel.org,
john.johansen@canonical.com, juri.lelli@redhat.com,
keescook@chromium.org, mcgrof@kernel.org,
martin.petersen@oracle.com, mattst88@gmail.com, mgorman@suse.de,
oleg@redhat.com, pbonzini@redhat.com, peterz@infradead.org,
rth@twiddle.net, richard@nod.at, serge@hallyn.com,
rostedt@goodmis.org, tglx@linutronix.de,
trond.myklebust@hammerspace.com, vincent.guittot@linaro.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
ceph-devel@vger.kernel.org, kvm@vger.kernel.org,
linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-m68k@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org,
linux-scsi@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH 0/8] signals: Support more than 64 signals
Date: Tue, 4 Jan 2022 13:33:16 -0800 [thread overview]
Message-ID: <CADCN6nz0ih2k7-LB9D3qJjQ9Dv5QAkn7KC9Ci-qcbMHTG7_F+A@mail.gmail.com> (raw)
In-Reply-To: <YdSzjPbVDVGKT4km@mit.edu>
Fair enough. I'll abandon the signals part of this and just send out
the VSTATUS/Control-T part, after I address some comments from Greg.
Thanks.
On Tue, Jan 4, 2022 at 12:52 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
> > I dug through the previous conversations and there is a little debate
> > about what makes sense for SIGPWR to do by default. Alan Cox remembered
> > SIGPWR was sent when the power was restored, so ignoring SIGPWR by
> > default made sense. Ted Tso pointed out a different scenario where it
> > was reasonable for SIGPWR to be a terminating signal.
> >
> > So far no one has actually found any applications that will regress if
> > SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only
> > defined to be sent to init, and init ignores all signals by default so
> > in practice SIGPWR is ignored by the only process that receives it
> > currently.
>
> As it turns out, systemd does *not* ignore SIGPWR. Instead, it will
> initiate the sigpwr target. From the systemd.special man page:
>
> sigpwr.target
> A special target that is started when systemd receives the
> SIGPWR process signal, which is normally sent by the kernel
> or UPS daemons when power fails.
>
> And child processes of systemd are not ignoring SIGPWR. Instead, they
> are getting terminated.
>
> <tytso@cwcc>
> 41% /bin/sleep 50 &
> [1] 180671
> <tytso@cwcc>
> 42% kill -PWR 180671
> [1]+ Power failure /bin/sleep 50
>
> > Where I saw the last conversation falter was in making a persuasive
> > case of why SIGINFO was interesting to add. Given a world of ssh
> > connections I expect a persuasive case can be made. Especially if there
> > are a handful of utilities where it is already implemented that just
> > need to be built with SIGINFO defined.
>
> One thing that's perhaps worth disentangling is the value of
> supporting VSTATUS --- which is a control character much like VINTR
> (^C) or VQUIT (control backslash) which is set via the c_cc[] array in
> termios structure. Quoting from the termios man page:
>
> VSTATUS
> (not in POSIX; not supported under Linux; status
> request: 024, DC4, Ctrl-T). Status character (STATUS).
> Display status information at terminal, including state
> of foreground process and amount of CPU time it has
> consumed. Also sends a SIGINFO signal (not supported on
> Linux) to the foreground process group.
>
> The basic idea is that when you type C-t, you can find out information
> about the currently running process. This is a feature that
> originally comes from TOPS-10's TENEX operating system, and it is
> supported today on FreeBSD and Mac OS. For example, it might display
> something like this:
>
> load: 2.39 cmd: ping 5374 running 0.00u 0.00s
>
> The reason why SIGINFO is sent to the foreground process group is that
> it gives the process an opportunity print application specific
> information about currently running process. For example, maybe the C
> compiler could print something like "parsing 2042 of 5000 header
> files", or some such. :-)
>
> There are people who wish that Linux supported Control-T / VSTATUS,
> for example, just last week, on TUHS, the Unix greybeards list, there
> were two such heartfelt wishes for Control-T support from two such
> greybeards:
>
> "It's my biggest annoyance with Linux that it doesn't [support
> control-t]
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024849.html
>
> "I personally can't stand using Linux, even casually for a very
> short sys-admin task, because of this missing feature"
> - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024898.html
>
> I claim, though, that we could implement VSTATUS without implenting
> the SIGINFO part of the feature. Previous few applications *ever*
> implemented SIGINFO signal handlers so they could give status
> information, it's the hard one, since we don't have any spare signals
> left. If we were to repurpose some lesser used signal, whether it be
> SIGPWR, SIGLOST, or SIGSTKFLT, the danger is that there might be some
> userspace program (such as a UPS monitoring program which wants to
> trigger power fail handling, or a userspace NFSv4 process that wants
> to signal that it was unable to recover a file's file lock after a
> server reboot), and if we try to take over the signal assignment, it's
> possible that we might get surprised. Furthermore, all of the
> possibly unused signals that we might try to reclaim terminate the
> process by default, and SIGINFO *has* to have a default signal
> handling action of Ignore, since otherwise typing Control-T will end
> up killing the current foreground application.
>
> Personally, I don't care all that much about VSTATUS support --- I
> used it when I was in university, but honestly, I've never missed it.
> But if there is someone who wants to try to implement VSTATUS, and
> make some Unix greybeards happy, and maybe even switch from FreeBSD to
> Linux as a result, go wild. I'm not convinced, though, that adding
> the SIGINFO part of the support is worth the effort.
>
> Not only do almost no programs implement SIGINFO support, a lot of CPU
> bound programs where this might be actually useful, end up running a
> large number of processes in parallel. Take the "parsing 2042 of 5000
> header files" example I gave above. Consider what would happen if gcc
> implemented support for SIGINFO, but the user was running a "make -j
> 16" and typed Control-T. The result would be chaos!
>
> So if you really miss Control-T, and it's the only thing holding back
> a few FreeBSD users from Linux, I don't see the problem with
> implementing that part of the feature. Why not just do the easy part
> of the feature which is perhaps 5% of the work, and might provide 99%
> of the benefit (at least for those people who care).
>
> > Without seeing the persuasive case for more signals I have to say that
> > adding more signals to the kernel sounds like a bad idea.
>
> Concur, 100%.
>
> - Ted
next prev parent reply other threads:[~2022-01-04 21:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-03 18:19 [RFC PATCH 0/8] signals: Support more than 64 signals Walt Drummond
2022-01-03 18:19 ` [RFC PATCH 3/8] signals: Use a helper function to test if a signal is a real-time signal Walt Drummond
2022-01-03 18:48 ` [RFC PATCH 0/8] signals: Support more than 64 signals Al Viro
2022-01-04 1:00 ` Walt Drummond
2022-01-04 1:16 ` Al Viro
2022-01-04 1:49 ` Al Viro
2022-01-04 18:00 ` Eric W. Biederman
2022-01-04 20:52 ` Theodore Ts'o
2022-01-04 21:33 ` Walt Drummond [this message]
2022-01-04 22:05 ` Eric W. Biederman
2022-01-04 22:23 ` Theodore Ts'o
2022-01-04 22:31 ` Walt Drummond
2022-01-07 19:29 ` Arseny Maslennikov
2022-05-19 12:27 ` Pavel Machek
2022-01-07 19:19 ` Arseny Maslennikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADCN6nz0ih2k7-LB9D3qJjQ9Dv5QAkn7KC9Ci-qcbMHTG7_F+A@mail.gmail.com \
--to=walt@drummond.us \
--cc=aacraid@microsemi.com \
--cc=anna.schumaker@netapp.com \
--cc=arnd@arndb.de \
--cc=bfields@fieldses.org \
--cc=bp@alien8.de \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=ceph-devel@vger.kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=dinguyen@kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=idryomov@gmail.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jejb@linux.ibm.com \
--cc=jirislaby@kernel.org \
--cc=jlayton@kernel.org \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mattst88@gmail.com \
--cc=mcgrof@kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=rth@twiddle.net \
--cc=serge@hallyn.com \
--cc=tglx@linutronix.de \
--cc=trond.myklebust@hammerspace.com \
--cc=tytso@mit.edu \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).