Re: signal-handling problems for "dd": some thoughts

[Paul Eggert]

address@hidden (Paul Jarc) writes:

>> The basic idea is that SIGUSR1 is reserved for use by the user,
>> and it's intended to be a fairly fatal signal: if part of a
>> multiprocess application doesn't know what to do with SIGUSR1, it's
>> supposed to exit immediately.
>
> This would seem to make SIGUSR1 entirely redundant with SIGTERM.

To some extent yes, but they are different signals, and applications
sometimes need more than one signal value.  (Sometimes they need more
than two, which is why there's a SIGUSR2.  :-)

Also, standard applications are required to clean up any temporary
files when sent SIGTERM; they aren't required to do this for SIGUSR1
or SIGUSR2.  There are a few other requirements for SIGTERM (e.g.,
"make x" is normally supposed to remove "x" if it's still building
"x", when sent SIGTERM) that do not apply to SIGUSR1 and SIGUSR2.

> As I read the previous quote, the restriction is on the kernel not
> to *send* SIGUSR1 "spontaneously" (as it does with SIGSEGV, SIGHUP,
> SIGCHLD, etc.), so that userspace programs can define their own
> semantics for it, and they can rest assured that it won't be
> triggered by some unrelated event that the kernel notices.

Yes that's right.

> (So I think dd would be allowed to do this too, if not for the
> specific restriction on its own page;

No, because the default for utilities (as specified in
<http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap01.html#tag_01_11>
under "ASYNCHRONOUS EVENTS" is that a utility must immediately
terminate when sent a SIGUSR1.

> Maybe POSIXLY_CORRECT would be enough to satisfy the requirement?

Yes, if we decide to depart from POSIX by default but conform if
POSIXLY_CORRECT is set, that conforms.  But I'd rather not resort to
POSIXLY_CORRECT if I can avoid it.