Recently I've been working with a cluster monitoring tool (ganglia) which aggregates system metrics from /proc/* on each machine.

  1. How is the data in /proc/* gathered?
    Who writes the data there? How often is the data updated?
  2. Can I tune the way it is gathered so that it is more accurate?

3 Answers 3



/proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information centre for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory. For example, 'lsmod' is the same as 'cat /proc/modules' while 'lspci' is a synonym for 'cat /proc/pci'. By altering files located in this directory you can even read/change kernel parameters (sysctl) while the system is running.

In other words, this is real-time information directly from the kernel/etc, not files that are periodically updated.

  • 2
    The answer is good, however it has a good basis and potential to be much more elaborate. I will leave as a sugestion to extend it a little more with how changing proc variables affects the system, how sysctl works, and provide a link. Commented Dec 16, 2015 at 3:40
  • 1
    @RuiFRibeiro While I agree there is a great deal more information that one can learn about /proc/, a full in-depth explanation of /proc/ was not the question, and a link that expands greatly on the subject was included.
    – Jason Rush
    Commented Dec 16, 2015 at 3:48
  • Somehow the link escaped me, thanks. The point of expanding the answer is your choice, more expanded answers usually get more points from others. Cheers! Commented Dec 16, 2015 at 3:50

The data in /proc is not updated at all. It is generated on demand.

When you read from /proc (or indeed from any file at all), you are calling into the kernel. If you're reading a "real" file, the kernel will then (subject to caching, permissions, etc.) traverse the filesystem and retrieve the data you requested. If you're reading a /proc "file," the kernel will generate the relevant data on the fly.

This technique has become rather popular, and is now widely used in different areas of the filesystem. For instance, the /sys virtual filesystem is very similar to /proc from an architectural standpoint, though the contents are entirely different. On modern systems, you may find that /dev is also a virtual filesystem, since it is otherwise rather painful to keep the files in /dev up-to-date with hardware realities. Some userland services provide their own virtual filesystems through FUSE.


The files in /proc are mostly implemented as device drivers. They're basically implemented in a similar way to serial devices (/dev/ttyS*) except that instead of returning data from hardware the programmer returns data generated by his program.

In a way, it's similar to a web server. Only, instead of listening to a tcp socket and responding, /proc files are devices drivers that listen for read requests and responding.

There is nothing in the design of Unix kernel drivers that forces device nodes to only be mounted in /dev therefore people took the opportunity to develop and standardize the /proc directory to contain virtual devices that return some run-time information. These days the Linux kernel includes dedicated methods to handle /proc drivers.

Here's an article about devices drivers that includes an example of a /proc driver: http://www.linuxdevcenter.com/pub/a/linux/2007/07/05/devhelloworld-a-simple-introduction-to-device-drivers-under-linux.html

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