mjhjmtu

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

#/bin/bash

while true; do
 echo $$;
 sleep 0.5;
done

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.

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

13791 fstat(3, 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, 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.

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.

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.

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(