lkml.org 
[lkml]   [2022]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 0/8] signals: Support more than 64 signals
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

\
 
 \ /
  Last update: 2022-01-04 22:35    [W:0.992 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site