5

This is a silly question for the sake of academics; I know where to get the UID information if I need it. According to the proc(5) man page:

       /proc/[number]/stat
              Status information about the process.  This is used by ps(1).  It is defined in /usr/src/linux/fs/proc/array.c.

       /proc/[number]/statm
              Provides information about memory status in pages.  The columns are:

       /proc/[number]/status
              Provides much of the information in /proc/[number]/stat and /proc/[number]/statm in a format that’s easier for humans to parse.

I find it interesting that stat doesn't contain information about the UID, EUID, etc. of a process, yet status does. Kind of odd that one is forced to use the "human readable" file instead. Does anyone happen to know the reason for this off-hand?

2

When handling data, much of the time, the key is to keep only data that's relevant to your particular set of tasks, and nothing more. Much of the data that's exposed under /proc is done so for a singular purpose, i.e. a tool that needs to have visibility to it etc.

Given the comments I would assume 3 things about /proc/[number]/stat:

  1. The data being displayed here is what's relevant to functions and data objects within /usr/src/linux/fs/proc/array.c.
  2. That data is also what's relevant to ps.
  3. Looking through the data that's here you'll notice that there is nothing here that's user specific. It's all geared towards processes.

NOTE: for #2. this is the process data that's relevant to ps. The processes owned by a user are kept in a different data structure within the Kernel elsewhere.

On the otherhand, with /proc/[number]/status, the comment pretty much tells you what this data is geared towards, a human reading it. So it's likely that this node within the Kernel serves no other purpose, from a tools perspective, then to collate data from other sources into a single place for the user to consume it.

Additional evidence

If you need more proof of this, look to this question I answered a while ago, titled: /proc/meminfo MemTotal =?. This question covered /proc/meminfo and it was a similar issue here too. Some of the data is exposed during the Kernel boot-up under dmesg log output. However that data, though memory related and perceived as relevant to /proc/meminfo was absent, again because it wasn't useful to:

  1. the target audience of tools that would be using /proc/meminfo
  2. Not relevant to the Kernel internal functions, methods, and data structures that made use of the data in /proc/meminfo.

References

  • Assumptions #1+#3 are probably close to the mark. #2 I'm less sold on, as ps does in fact need to be able to display RUID and EUID for a process depending on the format. They're probably looked up with syscalls instead of via /proc at that point. – Andrew B Nov 27 '13 at 1:04
  • Yes I should've qualified that bullet a little bit more. I meant the data related to a process, that relevant to ps. I'll update the A. – slm Nov 27 '13 at 2:28
  • 2
    @AndrewB For the record, ps looks it up in /proc/<pid>/status! It uses both the stat and status files, because neither contains all the bits of information it needs (uids are only in status, controlling terminal is only in stat... it's a mess). – Nicholas Wilson Jan 22 '14 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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