I wrote a simple script that echo-es its own PID every half a second:


while true; do
    echo $$
    sleep .5

I'm running said script (it says 3844 over and over) in one terminal and trying to tail the file descriptor in another one:

$ tail -f /proc/3844/fd/1

It doesn't print anything to the screen and hangs until ^c. Why?

Also, all of the STD file descriptors (IN/OUT/ERR) link to the same pts:

$ ls -l /proc/3844/fd/
total 0
lrwx------ 1 mg mg 64 sie 29 13:42 0 -> /dev/pts/14
lrwx------ 1 mg mg 64 sie 29 13:42 1 -> /dev/pts/14
lrwx------ 1 mg mg 64 sie 29 13:42 2 -> /dev/pts/14
lr-x------ 1 mg mg 64 sie 29 13:42 254 -> /home/user/test.sh
lrwx------ 1 mg mg 64 sie 29 13:42 255 -> /dev/pts/14

Is this normal?

Running Ubuntu GNOME 14.04.


4 Answers 4


Make a strace of tail -f, it explains everything. The interesting part:

13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) = 0
13791 fstatfs(3, {...}) = 0
13791 inotify_init()                    = 4
13791 inotify_add_watch(4, "/path/to/file", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) = 0
13791 read(4, 0xd981c0, 26)             = -1 EINTR (Interrupted system call)

What it does? It sets up an inotify handler to the file, and then waits until something happens with this file. If the kernel says tail through this inotify handler, that the file changed (normally, was appended), then tail 1) seeks 2) reads the changes 3) writes them out to the screen.

/proc/3844/fd/1 on your system is a symbolic link to /dev/pts/14, which is a character device. There is no such thing as some like a "memory map", which could be accessed by that. Thus, there is nothing whose changes could be signed to the inotify, because there is no disk or memory area which could be accessed by that.

This character device is a virtual terminal, which practically works as as if it were a network socket. Programs running on this virtual terminal are connecting to this device (just as if you telnet-ted into a tcp port), and writing what they want to write into. There are complexer things as well, for example locking the screen, terminal control sequences and such, these are normally handled by ioctl() calls.

I think, you want to somehow watch a virtual terminal. It can be done on linux, but it is not so simple, it needs some network proxy-like functionality, and a little bit of tricky usage of these ioctl() calls. But there are tools which can do that.

Currently I can't remember, which debian package has the tool for this goal, but with a little googling you could find that probably easily.

Extension: as @Jajesh mentioned here (give him a +1 if you gave me), the tool is named watch.

Extension #2: @kelnos mentioned, a simple cat /dev/pts/14 were also enough. I tried that, and yes, it worked, but not correctly. I didn't experimented a lot with that, but it seems to me as if an output going into that virtual terminal gone either to the cat command, or to its original location, and never to both. But it is not sure.

  • peterh's answer about tail is correct (the inotify watch bit), but he's incorrect in that it's actually very simple to do what you want: simply use cat instead of tail.
    – kelnos
    Commented Aug 29, 2014 at 12:29
  • @kelnos Thanks, I will try that and extend my answer with the results.
    – peterh
    Commented Aug 29, 2014 at 12:42
  • 1
    I still don't get it. I changed echo $$ to echo $$ >> foo so now there's a file and process opens it and appends to it every 0.5 seconds. I still can't access it via file descriptor and all file descriptors in /proc/$pid/fd/ (but 254 which links to test.sh script itself) link to /dev/pts/14. How does bash access foo it writes to?
    – cprn
    Commented Aug 29, 2014 at 15:45
  • 1
    odd, it appears to only work in some situations. using the script in the question, it doesn't work. but if i do "echo $$" in a shell, and then cat FD 1 on that pid in another shell, everything i type in the first shell is echoed in the second.
    – kelnos
    Commented Aug 30, 2014 at 20:07
  • 1
    @cprn Here we have a little inconsequent terminology. File can mean a consecutive stream of bytes in a background storage, but it can also mean anything addressable with a disk path. File descriptor means a small integer pointing to file... :-) But, the important thing is the kernel call part: tail -f watches for write events on the file, and if it happened, it puts to the output the increased part. Now a tty can have write events, but writes into it do not cause a file size increase.
    – peterh
    Commented May 9 at 16:08

Files in /dev/pts are not regular files, they are handles for virtual terminals. A pts behavior for reading and writing is not symmetrical (that is, what's written in there can later be read from it, like a regular file or a fifo/pipe), but mediated by the process which created the virtual terminal: some common ones are xterm or ssh or agetty or screen. The controlling process will usually dispatch key presses to processes which read the pts file, and render on screen what they write on the pts.

Thus, tail -f /dev/pts/14 will print the keys you tap on the terminal from which you started your script, and if you do echo meh > /dev/pts/14 the meh message will appear in the terminal.


Some time ago I found a kinda workaround that sometimes answers the necessity to check what's being outputted to STDOUT, assuming you have a pid of the process and you can bare the eyes unfriendly results:

sudo strace -p $pid 2>&1 | grep write\(

I guess, for this rather than tailing, what you need to do would be watching the output.

$ watch -n2 ls -l /proc/3844/fd/

Hope this is what you need.

  • 3
    This command will show the list of open fds every 2 seconds, not the content output on stdout.
    – Ángel
    Commented Aug 29, 2014 at 13:20
  • Ángel, true. He could use the watch with a cat to see the result on which descriptor he wants to monitor. I guess @peter-horvath, gave the perfect explanation for the question.
    – Jayesh
    Commented Aug 29, 2014 at 13:30
  • I know watch. What I'm trying to do is to peek the output of the already running process, so watch doesn't help.
    – cprn
    Commented Aug 29, 2014 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .