From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050406 Firefox/1.0.2 (Debian package 1.0.2-3) Description of problem: The access time, modification time, and attribute modification time attributes of files in the /proc filesystem change every time they are queried (by calling the stat function), even though they should not change. Function `int stat (const char *FILENAME, struct stat *BUF)' defined in `sys/stat.h' returns different values for the `st_atime', `st_mtime' and `st_ctime' member of the stat struct. Version-Release number of selected component (if applicable): kernel-2.4.21-27.0.2.ELsmp How reproducible: Always Steps to Reproduce: 1.run any process which will not exit in the background and note down its PID e.g. [redhatbox]$ vim & [1] 6310 [redhatbox]$ 2.compile the following code with g++ getTimeAttributes.cpp -o getTimeAttributes // begin code `getTimeAttributes.cpp' #include <iostream> #include <sys/stat.h> #include <stdio.h> int main( int argc, char** argv ) { int pid = atoi( argv[1] ); time_t atime; time_t mtime; time_t ctime; char tmp_str [128]; sprintf(tmp_str, "/proc/%d/", pid); struct stat sinfo; if (stat(tmp_str, &sinfo)) { atime = mtime = ctime = 0; } else { atime = sinfo.st_atime; mtime = sinfo.st_mtime; ctime = sinfo.st_ctime; } std::cout << "File: " << tmp_str << std::endl << "Access time: " << atime << std::endl << "Content modification time: " << mtime << std::endl << "Attribute modification time: " << ctime << std::endl; return 0; } // end code 3.run the command [redhatbox]$ getTimeAttributes 6310 4.rerun the command [redhatbox]$ getTimeAttributes 6310 This will print different values for the access, modification and attribute modification times, even though they should remain the same. Actual Results: ** 1st run ** File: /proc/6310/ Access time: 1114169780 Content modification time: 1114169780 Attribute modification time: 1114169780 ** 2nd run ** File: /proc/6310/ Access time: 1114169782 Content modification time: 1114169782 Attribute modification time: 1114169782 ** 3rd run ** File: /proc/6310/ Access time: 1114169785 Content modification time: 1114169785 Attribute modification time: 1114169785 Expected Results: ** 1st run ** File: /proc/6310/ Access time: 1114169780 Content modification time: 1114169780 Attribute modification time: 1114169780 ** 2nd run ** File: /proc/6310/ Access time: 1114169780 Content modification time: 1114169780 Attribute modification time: 1114169780 ** 3rd run ** File: /proc/6310/ Access time: 1114169780 Content modification time: 1114169780 Attribute modification time: 1114169780 Additional info: This bug does not occur in recent versions of the kernel (tested on 2.6.8 and works properly).
The files in /proc have no existence of their own. They are ephemera, invented on the spur of the moment when you look at them, forgotten once you look away. The only time that has any meaning for those files is "right now". So the 2.4 behaviour is not a bug. The 2.6 behaviour is nothing more than an artifact of the different way that those files are getting cached there after they are first referenced; fork a process, wait an hour and then query /proc, and you'll find that the timestamps are "now"; they were invented when you first looked at /proc, _not_ when the process was created. They have nothing to do with the process itself. So it is inappropriate to assign any significance to the timestamps in /proc; they mean nothing, and are vulnerable to change.