How do I know if dd is still working?
I've not used
ddall that much, but so far it's not failed me yet. Right now, I've had a
ddgoing for over 12 hours - I'm writing an image back to the disk it came from - and I'm getting a little worried, as I was able to
ddfrom the disk to the image in about 7 hours.
I'm running OSX 10.6.6 on a MacBook with a Core 2 Duo at 2.1ghz/core with 4gb RAM. I'm reading from a .dmg on a 7200rpm hard drive (the boot drive), and I'm writing to a 7200rpm drive connected over a SATA-to-USB connector. I left the blocksize at default, and the image is about 160gb.
EDIT: And, after 14 hours of pure stress, the
ddworked perfectly after all. Next time, though, I'm going to run it through
pvand track it with
strace. Thanks to everyone for all your help.
Not answering your question, but your times are quite high IMO. Did you remember to pass a bigger block size to dd other than the default 512 bytes? `dd ... bs=16M` is my suggestion, given your RAM, disk size and speed.
I didn't, simply because I wanted to play it safe. I'll try that next time, though. Thanks.
You can send
dda certain signal using the
killcommand to make it output its current status. The signal is
INFOon BSD systems (including OSX) and
USR1on Linux. In your case:
kill -INFO $PID
You can find the process id (
$PIDabove) with the
pscommand; or see pgrep and pkill alternatives on mac os x for more convenient methods.
As an example on Linux, you could make all active
ddprocesses output status like this:
pkill -USR1 -x dd
After outputting its status,
ddwill continue coping.
Checked the `man` page for `kill`, and there's no mention of `-USR1` - what does that do? I'm really nervous about running any form of `kill` on this process, as I have a client waiting on this to finish.
Start another `dd` doing something easy and try it on that before you risk breaking your big one. I don't know what USR1 stands for but my guess is it's a custom (user 1?) signal that different process might handle differently.
No, it definitely stopped the process and spit out "User defined signal 1". Good thing I tried it on something extraneous. :P
My Ubuntu box says to use `$ kill -s INFO $pid; wait $pid`. "On systems lacking the 'INFO' signal 'dd' responds to the 'USR1' signal instead, unless the 'POSIXLY_CORRECT' environment variable is set."
@kivetros: On BSD systems, you need to send the `INFO` signal. Linux doesn't have a SIGINFO and uses `USR1` instead.
The SIGUSRx signals are for programs to do what they want with, as opposed to having a standardized meaning. SIGWINCH, for example, is raised when the terminal has changed its size and the program might need to redraw its screen. The operating system doesn't send SIGUSRx's so they are available for custom uses.
Sending dd the USR1 signal _too soon_ after it has started (i.e. in a bash script, the line after you started it) will in fact terminate it. Put a 0.1 second sleep in between and it will output its progress properly. By the way, a very nice dd command to test USR1/INFO on is `dd if=/dev/zero of=/dev/null`. :)
BTW, all "true" BSDs send SIGINFO to foreground process group if status character (Ctrl+T by default) is sent to terminal. But I don't know whether is it true for MacOSX.
@DanLoewenherz Possibly you ran it too soon after starting `dd`? It should be functionally the same as using `kill`, it just saves the step of looking up the PID
@MichaelMrozek Odd...nope, ran it about 5 mins after starting. Weird, maybe it was just a fluke?
@Dan it does work if you have the right signal for the right platfom. Play with `dd if=/dev/zero of=/dev/null` and see what you can get sending different signals.
When I used the command `pkill -USR1 -x dd` my `dd` process stopped, i did not get a progress status, and I had to restart it. Why would this have happened?