Home / server / Questions / 346026
Accepted
tylerl
Asked: 2012-01-03 20:58:10 +0800 CST

linux procfs file times

  • 772

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?

linux

2 Answers

  1. Best Answer

    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.

    • 2

  2. /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.

    • 1