Grab standard input/ouput of a running process under FreeBSD/macOS

Question

Under Linux I often use /proc/<pid>/fd/[0,1,2] to access std[in,out,err] of any running process.

Is there a way to achieve the same result under FreeBSD and/or macOS ?

score 5 · Accepted Answer · edited May 23 '17 at 12:39

5

See this StackOverflow link for a dtrace based answer to this. I've tested it on FreeBSD and it works perfectly:

    capture() {
        sudo dtrace -p "$1" -qn '
            syscall::write*:entry
            /pid == $target && arg0 == 1/ {
                printf("%s", copyinstr(arg1, arg2));
            }   
        '   
    }

edited May 23 '17 at 12:39

Community

1

answered May 12 '17 at 20:15

Steve Wills

1,595

1

works great ! thanks and sorry for the delay. – M4rty May 23 '17 at 21:13
1

how can I write to the stdin of the running process? – Avba Dec 17 '20 at 11:36
How can I capture stdin of a running process (stdout works like above) on MacOS? – Michael Aigner Sep 03 '22 at 11:48

Claus Andersen · Answer 2 · 2017-05-24T15:09:43.930

0

procfs is also available in FreeBSD but from the man page it seems that fd is not implemented. Procfs is usully only used in FreeBSD for Linux compability.

The native replacement of procfs on FreeBSD is procstat which you can use with the -f parameter to get the file descriptor:

procstat -a -f

Another native tool to identify active files is fstat. Remember -m for memory mapped files if needed.

fstat -m

If you like to work through the file system then we have devfs which exposes fdescfs and you can access fd in the manner you request.

ls /dev/fd

Example:

echo -n Hello > hello.txt
echo " World!" | cat hello.txt /dev/fd/0

If you want something which is portable across system to Mac as well - then you could use the tool lsof (LiSt Open Files) which available as a package.

If portability is of concern you should read Portability of file descriptor links. It covers all bases.

edited May 24 '17 at 15:09

answered May 11 '17 at 12:46

Claus Andersen

3,384

Describing procstat as a replacement for procfs seems inaccurate to me. The initial commit for it here described it as providing "some of the missing functionality from procfs(4) and new functionality for monitoring and debugging specific processes." It wasn't meant to replace procfs, which existed in FreeBSD then and still exists. – Steve Wills May 12 '17 at 20:24
1

procfs for sure has its merits but it is not mounted by default for a reason. Procfs has not seen a lot of maintanence since and personally I would not rely on it for other than legacy reasons. But no - it is not officially deprecated. See some of Robert Watsons reasoning here https://lists.freebsd.org/pipermail/freebsd-hackers/2007-November/022228.html – Claus Andersen May 14 '17 at 10:09
I think, I miss something, when I use procstat -a -f I get the tty that launched it for exemple in my current test /dev/pts/2 , and I know I want fd1. But I can't put everything together. Can you provide an exemple? In my test (open cat in an xterm) I suppose the interesting line is : 56604 cat 1 v c rw------ 7 1788 - /dev/pts/2 But I can't simply tail -f /dev/pts/2, maybe I should try reading from the 1788 which is the offset or something similar. – M4rty May 23 '17 at 21:26
It is not quite what you are going for but you can monitor your pseudo terminal using watch like watch /dev/pts/0 or cat /dev/pts/0 | tee -a pts0log. Or going Python with psutil psutil.Process(pid=PID).get_open_files(). Understand the comment from Steve why he thought calling `procstat´ a replacement was inaccurate. It is not a 1:1 replacement. – Claus Andersen May 24 '17 at 15:06

Grab standard input/ouput of a running process under FreeBSD/macOS

2 Answers2