I wrote a simple script which echo-es its PID:


while true; do
    echo $$;
    sleep 0.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.

If you think this question belongs to SO or SU instead of UL, do tell.


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
    Aug 29, 2014 at 12:29
  • @kelnos Thanks, I will try that and extend my answer with the results.
    – peterh
    Aug 29, 2014 at 12:42
  • @kelnos cat doesn't work for me either, it hangs the same way tail does and all I can do is to ctrl+c.
    – cprn
    Aug 29, 2014 at 15:14
  • 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
    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
    Aug 30, 2014 at 20:07

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.

  • You're right to say I can write to the pts device but I can't seem to read from it. As in: tail -f /dev/pts/14 doesn't print the keys I tap on that terminal. It's an interesting answer, though. Thanks.
    – cprn
    Aug 29, 2014 at 15:07

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
    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
    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
    Aug 29, 2014 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.