How come dd only outputs when I press Ctl+t?

Question

This is with OSX. When I run this in a terminal

scottcarlson$ sudo dd if=Downloads/CentOS-7-x86_64-Everything-1511.iso of=/dev/disk2 2> Desktop/out.txt

and then this in another

tail -f Desktop/out.txt

it only updates the log when I press Ctlt in the first terminal with the dd. Is this because of the nature of dd?

I don't know exactly how it writes to devices, but could it be too demanding for the process to take a break and write to the log?

@jlliagre I believe I'm asking more precisely why it outputs when I press cntl+t. — a25bedc5-3d09-41b8-82fb-ea6c353d75ae, Jul 23 '16 at 01:19
Which is precisely explained here: http://unix.stackexchange.com/a/59076/2594 — jlliagre, Jul 23 '16 at 01:32
See also http://askubuntu.com/questions/215505/how-do-you-monitor-the-progress-of-dd — jlliagre, Jul 23 '16 at 01:35
Maybe I am misunderstanding that explanation, so is cntl+t a macro for kill -INFO $PID? — a25bedc5-3d09-41b8-82fb-ea6c353d75ae, Jul 23 '16 at 01:36
Kind of. It is actually directly sending the SIGINFO signal, just like Ctrl-C is sending the SIGQUIT one. On Linux you would send SIGUSR1 for the same effect, but there is no keyboard shortcut. — jlliagre, Jul 23 '16 at 01:56
Ahhhh. That makes sense. So it's just a built in macro for the SIGINFO signal. I am not very familiar with that so I will have to look it up. — a25bedc5-3d09-41b8-82fb-ea6c353d75ae, Jul 23 '16 at 02:17

score 1 · Answer 1 · answered Jul 23 '16 at 01:08

1

What you're seeing with ctlt is a summary of the running process information, not dd's output.

dd does not output any progress information, unlike what you seem to expect.

If you want to see the actual progress from another terminal window, look at the output file size changing. In this case you're writing to a raw disk, so patience is probably your best friend here.

answered Jul 23 '16 at 01:08

Julie Pelletier

7,622

Ok thank you. I originally did not think dd output anything based on my experience, but a Google search led me to think otherwise. Can you suggest a good method to see information about the transfer (like percent of transfer completed) for OS X? I have brew installed. In rhel I know how to do it but the same method does not work in OS X. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 01:13
Not in your current case where you're writing to a device, not a file. If it was a file, you could look at the size changing but with a device or partition, there is no way to monitor its progress. I can imagine many ways that it could be done but not as efficiently and since it's probably very slow already, just let it run until it finishes. – Julie Pelletier Jul 23 '16 at 01:14
Well here's to waiting around for 12 hours.. It's a 26gb file haha – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 01:23
That does seem quite slow. Are you reading and writing on the same device? What type of drive is the output device? – Julie Pelletier Jul 23 '16 at 01:27
Only writing and it's a 16gb usb 2.0 drive, I'm writing a very large iso. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 02:04
It's going at 50kb/s. ... If I remember right – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 02:11
That is slow. – Julie Pelletier Jul 23 '16 at 02:15
How is it supposed to fit 26GB of data on a 16GB disk? – Julie Pelletier Jul 23 '16 at 03:17
Hahahaha true.. I switched to a larger drive and ignorantly forgot. It's a 64gb Sandisk. Still use 2.0. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 03:21
If it's really running at 50KB/s, it will take around 6 days to complete. – Julie Pelletier Jul 23 '16 at 03:23
Guess I don't remember what the speed was. It must've been around 500kb/s. But that's besides the point – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Jul 23 '16 at 14:53

jlliagre · Accepted Answer · 2016-07-23T02:18:26.733

It only updates the log when I press Ctlt in the first terminal with the dd. Is this because of the nature of dd?

Yes. It is in the nature of dd to output its current status when it receives a given signal. Under most OSes, this signal is SIGUSR1, a standard signal but on OS X, it uses for the same a non standard signal named SIGINFO. Moreover, OS X has a tty driver setting that allows to send that specific signal with a key combination, CtrlT, just like CtrlC sends SIGQUIT on all OSes.

I don't know exactly how it writes to devices, but could it be too demanding for the process to take a break and write to the log?

You are precisely asking it to do that with the shortcut. Should you want to have regular automatic updates, nothing forbids you to do a simple shell loop like that one:

while kill -INFO $(pgrep dd); do sleep 5; done

This assumes pgrep is available on OS X. Otherwise, pick the pid of your dd command and use it as kill second argument.

score 0 · Answer 3 · answered Jul 23 '16 at 02:02

On OS-X, if you run stty -a you'll see that ^T is the key combination for status

% stty -a | grep '\^T'
        min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;

From man dd

 If dd receives a SIGINFO (see the status argument for stty(1)) signal,
 the current input and output block counts will be written to the standard
 error output in the same format as the standard completion message.  If

The two together mean that while dd is running, hitting ^T will cause a summary display to be written.

How come dd only outputs when I press Ctl+t?

3 Answers3