dd dies on SIGUSR1

[David Schultz]

On Mon, May 09, 2011, Chris Rees wrote:
> On 25 March 2011 03:37, David Schultz <das at freebsd.org> wrote:
> > On Wed, Mar 23, 2011, Eitan Adler wrote:
> >> > We are talking about a design decision taken decades ago, which quite
> >> > possibly was a mistake.
> >>
> >> Historical reasons are not be discounted, but in this case because the
> >> behavior is already non-portable, and already not be relied upon, so
> >> there is no reason that changing the default is harmful.
> >>
> >> > Again, how many people rely on USR1 to terminate a process?
> >>
> >> Hopefully none. Even if there are people who do rely on such behavior
> >> that reliance could be said to be a mistake or otherwise broken.
> >
> > Please see my previous message.  The historical behavior of SIGUSR1
> > terminating a process by default is standard, even on Linux.
> >
> > I believe one of the original uses of the signal was to allow
> > daemons and their children to signal each other.  In this use
> > case, if the notification can't be delivered because the recipient
> > is unprepared to accept it, termination is appropriate for a
> > fail-fast design.
> 
> Since the consensus seems to be for leaving as-is, perhaps someone
> could please close bin/155034?
> 
> You can state that I've abandoned it!

Looking into the solution originally proposed is still on my todo
list...  In researching it further, I noticed that even Linux
doesn't support this convention consistently: Most utilities die
on receipt of SIGUSR1, or fail to do anything useful.  dd appears
to be the sole exception.