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

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> I looked into GNU dd's signal handling and found some problems.

Thank you!

> The biggest is that GNU "dd" appropriates SIGUSR1 to mean "please
> issue a progress report on stderr".  POSIX doesn't allow this
> behavior: it requires "dd" to immediately exit when it gets SIGUSR1.

I suppose you're referring to this part of the POSIX spec:

    The signals SIGUSR1 and SIGUSR2 are commonly used by applications for
    notification of exceptional behavior and are described as ``reserved as
    application-defined'' so that such use is not prohibited. Implementations
    should not generate SIGUSR1 or SIGUSR2, except when explicitly requested
    by kill( ).

And so dd shouldn't use SIGUSR1, because some application (e.g., a
program that invokes dd) might use SIGUSR1 for something unrelated.

> Also, it's very difficult to implement SIGUSR1 support correctly: for
> example, the SIGUSR1 might interrupt a read or write to a slow device,
> causing "dd" to get a short block.

Good point.

> The simplest fix is to remove SIGUSR1 support from GNU "dd".  But this
> raises the issue: how many people use this "progress report" function?
> If there's a real need for it, we should provide it, but perhaps in a
> different way -- perhaps, for example, the user could specify a file
> descriptor that could be used to interrogate dd's status.

Lots of people have been asking for progress-bar support
in the coreutils over the years.  Here's a related idea and
some code to provide progress-bar support for several of the
coreutils programs:

  http://mail.gnu.org/archive/html/bug-coreutils/2004-02/msg00071.html

> If we do want to retain support for status reports triggered by
> SIGUSR1, I propose that this behavior be enabled only upon explicit
> user request, e.g., "dd stats=1".  This would conform to POSIX.
> However, I don't see any way of implementing it reliably for slow

Why not?
Because we can't rely on signal semantics to defer signals
while in the critical read or write sections?

> devices (short of having "dd" become multiprocess or multithreaded,
> which sounds pretty extreme), so in this case "dd stats=1" should be
> documented be buggy with slow devices.
>
> I can send you more details if you like, including a (undoubtedly
> buggy) draft of support for SIGUSR1 with an explicit stats=1 option.

The ideal would be to find an approach that avoids adding a new option
to each tool that supports a progress bar.