How do I know if dd is still working?

  • I've not used dd all that much, but so far it's not failed me yet. Right now, I've had a dd going 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 dd from 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 dd worked perfectly after all. Next time, though, I'm going to run it through pv and 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.

    In my experience, `dd` on Mac OS X has a tendency to freeze to the point where I can't even kill the process, but have to restart the system. I resort to doing work on a Linux VM then.

  • Caleb

    Caleb Correct answer

    10 years ago

    You can send dd a certain signal using the kill command to make it output its current status. The signal is INFO on BSD systems (including OSX) and USR1 on Linux. In your case:

    kill -INFO $PID
    

    You can find the process id ($PID above) with the ps command; or see pgrep and pkill alternatives on mac os x for more convenient methods.

    More simply, as AntoineG points out in his answer, you can type ctrl-T at the shell running dd to send it the INFO signal.

    As an example on Linux, you could make all active dd processes output status like this:

    pkill -USR1 -x dd
    

    After outputting its status, dd will continue coping.

    Oh, very cool. You can combine those with `pkill -USR1 -x dd`

    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.

    @Gilles thanks for tracking down the different signal on BSD.

    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.

    I can confirm that OSX also sends SIGINFO when using ctrl-t. Great tip!

    `CTRL+T` does it pretty well.

    @MichaelMrozek `pkill -USR1 -x dd` actually killed the dd process.

    @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.

    `kill -USR1` on OSX just seems to kill the `dd` process, lamentably.

    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?

    @ob1 Sounds like you used the wrong signal for your platform.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM

Tags used