Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

How frequently is the proc file system updated on Linux? Is it 20 milliseconds (time quantum)?

share|improve this question
1  
+1. This is a great homework question to ask students. Thanks. –  Jonathan Ben-Avraham May 5 '13 at 0:19
3  
@JonathanBen-Avraham Feel free to ask on meta whether the community allows you to create a "great homework" tag... 8-) –  Hauke Laging May 5 '13 at 0:22
add comment

2 Answers

up vote 26 down vote accepted

The information that you read from the proc filesystem is not stored on any media (not even in RAM), so there is nothing to update.

The purpose of the proc file system is to allow userspace programs to obtain or set kernel data using the simple and familiar file system semantics (open, close, read, write, lseek), even though the data that is read or written doesn't reside on any media. This design decision was deemed better (e.g. human readable and easily scriptable) for getting and setting data whose format could not be specified in advance than implementing something such as ASN1 encoded OIDs, which also would have worked fine.

The data that you see when you read from the proc filesystem is generated on-the-fly when you do a read from the begining of a file. That is, doing the read causes the data to be generated by a kernel callback function that is specific to the file you are reading. Doing an lseek to the begining of the file and reading again causes another call to the callback that generates the data again. Similarly, when you write to a writable file in the proc filesystem, a callback function is called that parses the input and sets kernel variables. The input data in it's raw form isn't stored.

The above is just a slightly more verbose way of saying what Hauke Laging states so succinctly. I suggest that you accept his answer.

share|improve this answer
    
If you need proof that this answer is true, try to run inotify on a "file" or directory in /proc (or /sys for that matter) ... its too bad, it would make udev completely unneeded if you could just tell a simple inotify process to run x when something appears in y –  technosaurus May 5 '13 at 3:42
    
+1 very nice answer to me Thanks!! –  Grijesh Chauhan May 5 '13 at 7:17
add comment

It is updated on every access. You see the state of the kernel in that moment. That's why the size shown for the "files" is not the real size. The real size can change and is determined the moment you access the file.

You could say, it may be not updated for days. If you don't look at it. :-)

share|improve this answer
4  
+1. It's a little like the saying, "If a tree falls in a forest and no one is around to hear it, does it make a sound?", i.e. "If there is a proc file system and no one reads it, does it exist?". –  Jonathan Ben-Avraham May 5 '13 at 0:08
    
@JonathanBen-Avraham You could say that about every FS, couldn't you? :-) But bear in mind that there are far more accesses to proc than one would guess. Comment it out in fstab, reboot, and all hell breaks loose... –  Hauke Laging May 5 '13 at 0:20
    
What I meant was that the data in a media-backed file system exists even when no one reads it at any particular moment. It doesn't come into existence at the moment of reading like proc and sys. You are correct, proc has a lot of readers. However, sys is a similar filesystem that you can comment out of fstab, at least on smaller systems and still run Ok. Cheers. –  Jonathan Ben-Avraham May 5 '13 at 0:27
3  
So is the cat dead or not? Take a look and see. It's dead Jim. Poor cat. –  Shutupsquare May 5 '13 at 7:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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