Remotely monitoring the status of DD

Question

I have a long dd process running on a Debian system from the local console.

I know that I can send USER1 or CTRL+T on the local console, but my only means for the time being is to monitor it via ssh. Google has been unfortunately unhelpful here.

Is there a simple way to monitor it's progress remotely without stopping the current task?

Answer 1

With pv

pv can watch another process. The relevant part of man 1 pv:

-d PID[:FD], --watchfd PID[:FD]

Instead of transferring data, watch file descriptor FD of process PID, and show its progress. The pv process will exit when FD either changes to a different file, changes read/write mode, or is closed; other data transfer modifiers - and remote control - may not be used with this option.

If only a PID is specified, then that process will be watched, and all regular files and block devices it opens will be shown with a progress bar. The pv process will exit when process PID exits.

There are restrictions though:

• This only works for regular files and block devices. If your dd is in the middle of a pipeline, pv -d won't watch its stdin or stdout. Progress bar makes no sense in this case, still you may want to see throughput. But even if you explicitly specify PID:0 or PID:1, this won't work.
• Normally, as a regular user you cannot watch another user's processess.

The advantage is this approach is totally non-intrusive. It shouldn't affect the running dd in any way.

---

With reptyr

Another approach is with reptyr; see this answer of mine.

Start screen or tmux and use reptyr to attach the running dd to the new terminal. If this succeeds then you will be able to see dd's reaction to signals in the new terminal. Detach from screen/tmux and reattach if needed.

Notes:

• dd's reaction to signals will no longer appear in the old terminal.
• reptyr will redirect relevant file descriptors and change the controlling terminal of dd; so this is intrusive in a way. My advice is to try this with a "scratch monkey dd" first.
• In some cases (e.g. dd in a pipeline) reptyr is unable to attach. Then reptyr -T may work, but it will affect other processes, not only dd. Please see man 1 reptyr for details.

Answer 2

Now that the long dd command is running, it is too late to redirect its output. Maybe you are far from the console and you cannot use screen or to create a FIFO for its stderr...

... but you can still use two ssh session and strace !

On the first ssh session you can write

sudo strace -ewrite -p `pgrep ^dd`  2>&1 | grep -v "write(1,"

On the second instead (read the warning note below for the signal to use -SIGUSR1 or SIGINFO)

kill -USR1 $(pgrep ^dd)

And read a not so nice output from the first similar to the one below

Process 26176 attached
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=29517, si_uid=0} ---
write(2, "329094980+0 records in\n329094979"..., 47) = 47
write(2, "168496629248 bytes (168 GB) copi"..., 34) = 34
write(2, ", 109.221 s, 1.5 GB/s\n", 22) = 22

---

^{Note: Unfortunately (even if differently reported) the command kill -USR1 $(pgrep ^dd) will force the running dd processes to write to their original stderr. For this it was needed to modify the original answer (you can see in the version history).
Warning: As reported on this other answer the signal to send with kill instead of -USR1 may depend from the Linux distro. Under OpenBSD -SIGINFO under Ubuntu SIGUSR1. Check it carefully in advance a wrong one can terminate the process !}