GNU bug report logs -
#9620
dd: bogus behavior when interrupted
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Tue, 27 Sep 2011 19:36:01 UTC
Severity: normal
Tags: notabug
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9620 in the body.
You can then email your comments to 9620 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#9620
; Package
coreutils
.
(Tue, 27 Sep 2011 19:36:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Tue, 27 Sep 2011 19:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This happened with coreutils 8.13 on Fedora 14 x86-64
(coreutils compiled with GCC 4.6.1). I interrupted
'dd' with control-C, but it didn't respond right away;
instead, it churned away and created the entire output file,
issuing a bogus diagnostic about the input file. Here's
the transcript:
$ dd if=/dev/zero of=$HOME/junk/zero bs=1024 count=1000000
^C1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB) copied, 20.1583 s, 50.8 MB/s
dd: closing input file `/dev/zero': Bad file descriptor
$ ls -l zero
-rw-r--r-- 1 eggert eggert 1024000000 Sep 27 12:18 zero
The problem with the diagnostic is intermittent. It usually
does not happen. Usually, there's simply an unconscionably long
wait between the time I type ^C and the time that dd exits, e.g.:
$ dd if=/dev/zero of=zero bs=1024 count=1000000
^C487034+0 records in
487034+0 records out
498722816 bytes (499 MB) copied, 11.6897 s, 42.7 MB/s
(here I waited about 10 seconds between the time I typed
^C and the time that dd exited).
The filesystem is ext4 atop md (RAID-1).
The same problem occurs with /bin/dd (coreutils 8.5) so
if it is a coreutils bug it's not a new one.
Don't have time to debug this right now but thought I'd
get a bug report into the system. Quite possibly it is not
a coreutils bug at all, but a kernel bug, but in that case
where do I report it? to a Fedora mailing list?
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9620
; Package
coreutils
.
(Tue, 27 Sep 2011 20:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On 09/27/2011 12:33 PM, Paul Eggert wrote:
> This happened with coreutils 8.13 on Fedora 14 x86-64
> (coreutils compiled with GCC 4.6.1). I interrupted
> 'dd' with control-C, but it didn't respond right away;
> instead, it churned away and created the entire output file,
> issuing a bogus diagnostic about the input file. Here's
> the transcript:
>
> $ dd if=/dev/zero of=$HOME/junk/zero bs=1024 count=1000000
> ^C1000000+0 records in
> 1000000+0 records out
> 1024000000 bytes (1.0 GB) copied, 20.1583 s, 50.8 MB/s
> dd: closing input file `/dev/zero': Bad file descriptor
> $ ls -l zero
> -rw-r--r-- 1 eggert eggert 1024000000 Sep 27 12:18 zero
>
[snip]
> Quite possibly it is not
> a coreutils bug at all, but a kernel bug, but in that case
> where do I report it? to a Fedora mailing list?
https://bugzilla.redhat.com
Create an account (requires e-mail address and password)
or login using old account; select: New, Fedora, Fedora;
choose Component: kernel; enter details. Use <tab> to
switch fields (including Summary:); beware that <Enter>
activates and Submits a mostly-empty bug report.
--
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9620
; Package
coreutils
.
(Tue, 27 Sep 2011 21:24:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 9620 <at> debbugs.gnu.org (full text, mbox):
On 09/27/2011 08:33 PM, Paul Eggert wrote:
> This happened with coreutils 8.13 on Fedora 14 x86-64
> (coreutils compiled with GCC 4.6.1). I interrupted
> 'dd' with control-C, but it didn't respond right away;
> instead, it churned away and created the entire output file,
> issuing a bogus diagnostic about the input file. Here's
> the transcript:
>
> $ dd if=/dev/zero of=$HOME/junk/zero bs=1024 count=1000000
> ^C1000000+0 records in
> 1000000+0 records out
> 1024000000 bytes (1.0 GB) copied, 20.1583 s, 50.8 MB/s
> dd: closing input file `/dev/zero': Bad file descriptor
> $ ls -l zero
> -rw-r--r-- 1 eggert eggert 1024000000 Sep 27 12:18 zero
>
> The problem with the diagnostic is intermittent. It usually
> does not happen. Usually, there's simply an unconscionably long
> wait between the time I type ^C and the time that dd exits, e.g.:
>
> $ dd if=/dev/zero of=zero bs=1024 count=1000000
> ^C487034+0 records in
> 487034+0 records out
> 498722816 bytes (499 MB) copied, 11.6897 s, 42.7 MB/s
>
> (here I waited about 10 seconds between the time I typed
> ^C and the time that dd exited).
>
> The filesystem is ext4 atop md (RAID-1).
>
> The same problem occurs with /bin/dd (coreutils 8.5) so
> if it is a coreutils bug it's not a new one.
>
> Don't have time to debug this right now but thought I'd
> get a bug report into the system. Quite possibly it is not
> a coreutils bug at all, but a kernel bug, but in that case
> where do I report it? to a Fedora mailing list?
I think this is a kernel signal propagation bug that I noticed on Fedora 14 too
and I think Linda Walsh reported the same thing on the kernel list.
I didn't notice it on later kernels so I didn't pursue it.
Note I didn't notice errors, just delays.
BTW that ^C being displayed (started around Fedora 11 time (2.6.30))
is very annoying, especially when inserted in the middle of an ANSI code.
I mentioned that previously here:
http://mail.linux.ie/pipermail/ilug/2011-February/106723.html
cheers,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9620
; Package
coreutils
.
(Tue, 27 Sep 2011 21:34:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 9620 <at> debbugs.gnu.org (full text, mbox):
=?UTF-8?Q?P=C3=A1draig?= Brady writes:
>
> BTW that ^C being displayed (started around Fedora 11 time (2.6.30))
> is very annoying, especially when inserted in the middle of an ANSI code.
> I mentioned that previously here:
> http://mail.linux.ie/pipermail/ilug/2011-February/106723.html
I've been annoyed by that too. So annoyed that I patched my kernel to get rid
of it.
It was added between 2.6.24 and 2.6.25. Here's the commit message:
|commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961
|Author: Joe Peterson <joe <at> skyrush.com>
|Date: Wed Feb 6 01:37:38 2008 -0800
|
| tty: enable the echoing of ^C in the N_TTY discipline
|
| Turn on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g. ctrl-C
| will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR).
|
| Linux seems to be the only unix-like OS (recently I've verified this on
| Solaris, BSD, and Mac OS X) that does *not* behave this way, and I really
| miss this as a good visual confirmation of the interrupt of a program in
| the console or xterm. I remember this fondly from many Unixs I've used
| over the years as well. Bringing this to Linux also seems like a good way
| to make it yet more compliant with standard unix-like behavior.
|
| [akpm <at> linux-foundation.org: coding-style fixes]
| Cc: Alan Cox <alan <at> lxorguk.ukuu.org.uk>
| Signed-off-by: Andrew Morton <akpm <at> linux-foundation.org>
| Signed-off-by: Linus Torvalds <torvalds <at> linux-foundation.org>
And here's what I use to kill it (committed to my own git tree which is
exported to no one and has been seen by nobody but me until now):
commit 0b76f0a49a52ac37fb220f1481955426b6814f86
Author: Alan Curry <pacman <at> kosh.dhis.org>
Date: Wed Sep 22 16:35:01 2010 -0500
The echoing of ^C when a process is interrupted from tty may be more like
what the real unixes do, but this is a case where Linux was better. Put it
back the way it was.
When a command's output ends with an incomplete line, the shell can do one
of two things, both of them bad: engage its command line editor with the
cursor in the wrong column, or force the cursor to the first column before
printing the prompt, which obliterates the incomplete line, hiding actual
program output.
The echo of ^C immediately followed by process death is an instance of this
generally bad "command output ends with incomplete line" behavior.
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index c3954fb..70f5698 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1194,10 +1194,12 @@ send_signal:
}
if (I_IXON(tty))
start_tty(tty);
+#if 0 /* This echoing is a sucky new feature. --Pac. */
if (L_ECHO(tty)) {
echo_char(c, tty);
process_echoes(tty);
}
+#endif
if (tty->pgrp)
kill_pgrp(tty->pgrp, signal, 1);
return;
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9620
; Package
coreutils
.
(Sat, 15 Oct 2011 08:48:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 9620 <at> debbugs.gnu.org (full text, mbox):
tags 9620 notabug
close 9620
thanks
Pádraig Brady wrote:
> On 09/27/2011 08:33 PM, Paul Eggert wrote:
>> This happened with coreutils 8.13 on Fedora 14 x86-64
>> (coreutils compiled with GCC 4.6.1). I interrupted
>> 'dd' with control-C, but it didn't respond right away;
>> instead, it churned away and created the entire output file,
>> issuing a bogus diagnostic about the input file. Here's
>> the transcript:
>>
>> $ dd if=/dev/zero of=$HOME/junk/zero bs=1024 count=1000000
>> ^C1000000+0 records in
>> 1000000+0 records out
>> 1024000000 bytes (1.0 GB) copied, 20.1583 s, 50.8 MB/s
>> dd: closing input file `/dev/zero': Bad file descriptor
>> $ ls -l zero
>> -rw-r--r-- 1 eggert eggert 1024000000 Sep 27 12:18 zero
>>
>> The problem with the diagnostic is intermittent. It usually
>> does not happen. Usually, there's simply an unconscionably long
>> wait between the time I type ^C and the time that dd exits, e.g.:
>>
>> $ dd if=/dev/zero of=zero bs=1024 count=1000000
>> ^C487034+0 records in
>> 487034+0 records out
>> 498722816 bytes (499 MB) copied, 11.6897 s, 42.7 MB/s
>>
>> (here I waited about 10 seconds between the time I typed
>> ^C and the time that dd exited).
>>
>> The filesystem is ext4 atop md (RAID-1).
>>
>> The same problem occurs with /bin/dd (coreutils 8.5) so
>> if it is a coreutils bug it's not a new one.
>>
>> Don't have time to debug this right now but thought I'd
>> get a bug report into the system. Quite possibly it is not
>> a coreutils bug at all, but a kernel bug, but in that case
>> where do I report it? to a Fedora mailing list?
>
> I think this is a kernel signal propagation bug that I noticed on Fedora 14 too
> and I think Linda Walsh reported the same thing on the kernel list.
> I didn't notice it on later kernels so I didn't pursue it.
> Note I didn't notice errors, just delays.
Thanks for the report.
I confirm the same behavior with an ext4 partition and no md/lvm
using linux-2.6.40.6-0.fc15.x86_64.
However, with ext4 and linux-3.1.0-0.rc9.git0.0.fc17.x86_64 (rawhide)
in a VM the ^C takes effect immediately, so this is probably fixed
in the Fedora 16 kernels, too.
So I've marked this notabug and closed it.
> BTW that ^C being displayed (started around Fedora 11 time (2.6.30))
> is very annoying, especially when inserted in the middle of an ANSI code.
> I mentioned that previously here:
> http://mail.linux.ie/pipermail/ilug/2011-February/106723.html
Added tag(s) notabug.
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Oct 2011 08:48:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
9620 <at> debbugs.gnu.org and Paul Eggert <eggert <at> cs.ucla.edu>
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Oct 2011 08:48:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Nov 2011 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.