It is usually easy to know which process or processes are writing to a given file in Linux, since we either know its origin and its nature beforehand (for example the Apache access_log), or we can easily find it out with the fuser or lsof commands. However, sometimes it will happen that although we know the role and purpose of a file, there are so many applications accesing it simultaneously that it is very difficult to know which of them is the one that reads/writes the most or does so in a precise moment. Knowing this would be very useful to learn for example why a log file is growing excessively or which application is making an abusive use of system resources , either by mistake or intentionally.

In order to get this information in Linux we have the fatrace command, which displays all file access events that occur within the whole system , giving us information about the file involved, the name and PID of the process responsible for that event and the event type, ie whether the file was opened, read, written or closed.

Normally the fatrace command will not be present in your system, but you can install it from your Linux distribution’s repositories as usual:

– Debian / Ubuntu:

$ sudo apt-get install fatrace

– Centos / Fedora / Red Hat:

$ sudo yum install -y fatrace

Once installed, you can see which processes read or write to a file in real time running the command like this:

$ sudo fatrace -f W | grep .xsession-errors
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors 
konsole(13009): W /home/daniloaz/.xsession-errors

In the example above you can see how the fatrace command displays lines that are repeated hundreds of times just by moving the mouse a bit, which is clearly indicating that the konsole process with PID 13009 has some kind of fault that is causing it to write inordinately to the .xsession-errors file. And this information was obtained while other processes kept writing simultaneously to the same file, which was our initial goal.