Score:1

how to see the verbose output of a process that is running that writes to a file (shred)

in flag

I am running the shred command to securely wipe some storage.

I would like to see its progress, but have lost the ssh terminal that was running the command.

Is there a way that I can use to see the verbose output of the shred command from a new ssh terminal?

I have tried to hook into and view the output from /proc/pid/fd/0 1 2 etc but it just shows the random characters from /dev/urandom. I tried using strace, but the same file descriptors were available, with the same results. Shred shows 0, 1, 2, 3, and 4 fd, but they are all showing the random output.

MTIA, waiting patiently with stethoscope against drive...

in flag
Does this answer your question? https://unix.stackexchange.com/questions/31824/how-do-i-attach-a-terminal-to-a-detached-process
Ptit Xav avatar
pn flag
Using «ps -eaf | grep shred» may show you the shred command parameter and may where output was redirected if on command line.
miller the gorilla avatar
in flag
ps -eaf just lists the command and flags that were used to invoke the process. I am going to try and get the stackexchange link to work now.
miller the gorilla avatar
in flag
no joy. and reptyr command doesn't work because shred uses subprocesses.
Score:0
cl flag
A.B

On Linux (since OP mentioned /proc/pid/fd/0 which is a Linux thing), for any tool that is doing sequential operations, the method below in 3 steps can be used:

  1. Figure out the PID of the tool

    eg:

    # pgrep ^shred$
    699
    
  2. Note for this PID the file descriptor(s) of interest that is reading or writing

    For example with ls -l /proc/<pid>/fd/ or stat -c %N /proc/<pid>/fd/<FD> or lsof ... ...

    Example:

    # ls -l /proc/699/fd/
    total 0
    lrwx------ 1 root root 64 May 24 11:40 0 -> /dev/pts/6
    lrwx------ 1 root root 64 May 24 11:40 1 -> /dev/pts/6
    lrwx------ 1 root root 64 May 24 11:40 2 -> /dev/pts/6
    l-wx------ 1 root root 64 May 24 11:40 3 -> /dev/loop7
    

    Here the FD of interest is 3. It could have been FD 4 (like appears to be OP's case in this comment) or any other, depending on the command, the version of this command or its options when invoked.

  3. Query the kernel, using /proc/<pid>/fdinfo/<fd> about additional information:

    /proc/[pid]/fdinfo/ (since Linux 2.6.22)

    [...] The files in this directory are readable only by the owner of the process.

    (or by root or at least a process with the adequate capability.)

    The contents of each file can be read to obtain information about the corresponding file descriptor. [...]

    The fields are as follows:

    pos This is a decimal number showing the file offset.
    [...]

    For example:

    # cat /proc/699/fdinfo/3
    pos: 286785536
    flags:   0140001
    mnt_id:  830
    ino: 39
    

    or:

    # awk '/^pos:/ { print $2 }' /proc/699/fdinfo/3
    286785536
    

    So in this example shred is currently writing at position 286785536 ( ~ 273MiB).

This method doesn't require any cooperation from the tool: it doesn't have to be run in a terminal, be run in verbose mode, have any text output anywhere, log anything anywhere, to support handling a special signal (like dd does) to dump information, nor be ptrace()-ed: the kernel provides the current information through /proc.

miller the gorilla avatar
in flag
Thanks, but I have tried examining the file descriptors. I have the following: ```lrwx------ 1 root root 64 May 23 11:06 0 -> '/dev/pts/0 (deleted)' lrwx------ 1 root root 64 May 23 11:06 1 -> '/dev/pts/0 (deleted)' lrwx------ 1 root root 64 May 23 11:06 2 -> '/dev/pts/0 (deleted)' lr-x------ 1 root root 64 May 23 11:06 3 -> /dev/urandom l-wx------ 1 root root 64 May 23 16:45 4 -> /dev/sda``` It might be because I tried reading with strace...
A.B avatar
cl flag
A.B
So it's obviously FD number 4 in your case: /dev/sda . Did you read the last part of my answer, with `fdinfo` (not just `fd`)?
miller the gorilla avatar
in flag
I missed the fdinfo, as you suggested, but I get only the following: ```pos: 0 flags: 02004001 mnt_id: 13 ino: 27936``` and it doesn't seem to change. The other fdinfos are the same.
A.B avatar
cl flag
A.B
Considering the example I provided was with really using the `shred` command and observing what it's doing, I'm a bit surprised your shred command is doing nothing and didn't even start doing anything (pos: 0). Did you use cat /proc/PID/fdinfo/4 (with the correct pid and the fd number 4, not 3)?
A.B avatar
cl flag
A.B
I think there is a problem on your system, but I'd rather not help debug, because I don't want to risk giving the wrong command that would affect something else.
miller the gorilla avatar
in flag
According to top, shred is working away, and I used the correct pid, and tried all the fdinfos, which read almost exactly the same, the fdinfo in the above comment is 4. Its a raspberry py 2b, so running a 32 bit debian, I don't know if that makes any difference.
miller the gorilla avatar
in flag
Yes, now I take a closer look, there is some system error/misconfiguration. I will reinstall. Thanks for your help.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.