Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When examining a "long" directory listing of a /proc/<pid>/ directory under Linux, I've noticed that the pseudo-file entries within the directory have sometimes different times associated with them.

From what I know of how the internals work, there aren't any "arbitrary" or "unpredictable" attributes in the structure, everything is deterministic, everything (including the file times) has to be determined somewhere based on some criteria; whether or not that criteria is useful is the important question.

For example, the timestamp on the directory itself (/proc/<pid>/) seems to reflect the start time of the corresponding process (process ID, at least -- it is not updated by a call to exec), while various entries such as proc/<pid>/fd/ or /proc/<pid>/cwd might be a different value. My best guess is that many of these cache the time that information was first retrieved, but it's difficult to tell.

Is there any useful knowledge to be gained here?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

As you may know, the files under /proc are in-memory files which means they don't exist on the hard drive. However, they can be treated as any other file. I don't see any special meaning of the modification time of these files. They are just like any other file under your file system.

You can try to check the time of one file and then touch it. As expected, the file modification time will be updated.

share|improve this answer

/proc is just another file system, end entries within it are created just as in any other file system. If you create a process, then /proc/<pid>/ entry is created to hold data on the process. When this process opens a file descriptor, then an entry is created within /proc/<pid>/fd/.

As for useful knowledge, I didn't have opportunity to use contents of /proc/<pid>/ for anything, but I expect one day I might. It depends a lot of what is useful for you. Sysadmin would find different things interesting than a security expert, than a db admin. Still, it is good to know, that there is this kind of data available. One day it may come handy, but I would not invest too much time in learning nuts and bolts of this problem. That is because for me personally this would be poor time investment. Your mileage may vary :).

Edit: I was unable to fit my response to tylerl's comment within a comment, so it goes in here.

tylerl, you are right and wrong at the same time, depending on how one looks at the problem (think: wave/particle duality of light). You are certainly right when you say that procfs is not a "real" file system. You cannot create directories or files, or store data in there. Yes, it is an API that allows access to some kernel structures, it definitely does not create any on-disk structures. I am not so sure about in-memory structures (Where is [cm]time of directories in /proc stored?), but I admit ignorance and won't argue the point.

On the other hand, when you want to explore procfs, look at what is in there, and learn from entries in there, you can to a large extent treat it as "just another file system". You can read some "files" and you can write (usually strictly defined values) into some "files". When you create a process (say, run bash &), a /proc/<pid> entry will have creation date corresponding to the time of the process creation. I think, that for the "see what is there" model, a good enough approximation is "this entry is created in the file system at the process creation time". Sure, strictly speaking, it may be a lie. Still, it's a very useful lie if you do not need the whole mountain of truth dumped on you.

share|improve this answer
    
Well, actually - I can tell you with certainty that your first paragraph is false. The proc filesystem type is not a real filesystem, and entries aren't "created" in response to system events the way they are, say, in udev. Instead, the OS responds to queries (e.g. file and directory access) by synthesizing and returning the correct data on-the-spot. It's not so much an object as it is an API. It may cache results, but it never creates an actual in-memory or on-disk file structure anywhere. –  tylerl Jan 3 '12 at 18:50
    
@tylerl Thanks for the comment. I've responded to it in an edit. –  Paweł Brodacki Jan 4 '12 at 8:15

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.