When using the dd command on Linux, it can be frustrating to not see any output. This is especially true in cases where the process can take many hours (which can be quite common with dd).
In this post, we’ll start a dd process, then after the fact, we will monitor its progress with a kill signal.
After double and triple checking we’ve got the right output destination, let’s start wiping the /dev/sdd drive.
$ sudo dd if=/dev/zero of=/dev/sdd bs=4096
By default here, dd will not show any output until it is finished copying data.
In a separate terminal, let’s find the PID or Process ID of the dd command we’ve just run:
$ pgrep ^dd
23863
We can now issue a USR1 signal to the process with the kill command:
$ sudo kill -USR1 23863
As long as you only have one dd process running on your machine, this can also be combined into one command:
$ sudo kill -USR1 $(pgrep ^dd)
In the terminal with dd running, you’ll now see the current status of dd printed out like so:
$ sudo dd if=/dev/zero of=/dev/sdd bs=4096
4096986+0 records in
4096986+0 records out
16781254656 bytes (17 GB, 16 GiB) copied, 334.96 s, 50.1 MB/s
The output on the last line here is:
You can run the kill command as often as you like and dd will just append its latest status output each time:
$ sudo dd if=/dev/zero of=/dev/sdd bs=4096
4096986+0 records in
4096986+0 records out
16781254656 bytes (17 GB, 16 GiB) copied, 334.96 s, 50.1 MB/s
4467535+0 records in
4467535+0 records out
18299023360 bytes (18 GB, 17 GiB) copied, 368.752 s, 49.6 MB/s
If you you want this output to be constantly updated, one way to do that is to call the kill command with the watch command
$ watch -n30 'sudo kill -USR1 $(pgrep ^dd)'
In this case, the -n flag to watch calls the kill command every 30 seconds.
Now your output will keep ticking away, every 30 seconds:
$ sudo dd if=/dev/zero of=/dev/sdd bs=4096
4096986+0 records in
4096986+0 records out
16781254656 bytes (17 GB, 16 GiB) copied, 334.96 s, 50.1 MB/s
4467535+0 records in
4467535+0 records out
18299023360 bytes (18 GB, 17 GiB) copied, 368.752 s, 49.6 MB/s
6692757+0 records in
6692757+0 records out
27413532672 bytes (27 GB, 26 GiB) copied, 571.352 s, 48.0 MB/s
7020820+0 records in
7020820+0 records out
28757278720 bytes (29 GB, 27 GiB) copied, 601.372 s, 47.8 MB/s
7347917+0 records in
7347917+0 records out
30097068032 bytes (30 GB, 28 GiB) copied, 631.384 s, 47.7 MB/s
7676019+0 records in
7676019+0 records out
31440973824 bytes (31 GB, 29 GiB) copied, 661.392 s, 47.5 MB/s
8005246+0 records in
8005246+0 records out
32789487616 bytes (33 GB, 31 GiB) copied, 691.412 s, 47.4 MB/s
8333692+0 records in
8333692+0 records out
34134802432 bytes (34 GB, 32 GiB) copied, 721.416 s, 47.3 MB/s
8661499+0 records in
8661499+0 records out
35477499904 bytes (35 GB, 33 GiB) copied, 751.444 s, 47.2 MB/s
8988738+0 records in
8988738+0 records out
36817870848 bytes (37 GB, 34 GiB) copied, 781.46 s, 47.1 MB/s
The beauty of using kill signals here is that you can check on a dd process at any point, so even if you’ve started a lengthy copy process, you don’t need to stop and restart it just to see the progress, as you would if you were to pipe the data through pv.
Just as a reference for how long this hard drive wiping (zeroing) process takes, this was a 1TB hard drive, connected over USB in a dock, and the whole dd process took 22320.4 seconds. That’s about 6 hours and 12 minutes.
Tags: Linux
Posted on 19 June 2018. blog comments powered by DisqusRecent Posts:
How to monitor the progress of a dd process, even after it has started.
Monitoring frequency drift on the RTL SDR dongle
High entropy passwords are serious business! Here some little helpers to create better ones.
Running Linux and need to look busy quick? Try this little bit of command line fun :)
Bash scripts and command line examples are often littered with ampersands. Here's what they do.