[process] Collect process stat files

[rh-jhester]

The /proc/ subdirectory for a process contains many files, most of which the report doesn't capture. One of those files is stat, which contains, among other pieces of information, the CPU on which the process is running. This information is not contained in any of the files that the report currently collects, and is important for troubleshooting, e.g., isolcpus or other scheduling issues. The status file contains the field Cpus_allowed and Cpus_allowed_list, but this is not the same information. The underlying task_struct has separate members for the current CPU and the allowed CPU mask (list). The stat file is quite small and should be included in the report since it contains important information not contained elsewhere.

Signed-off-by: Jesse Hester [email protected]

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• [ X] Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• [ X] Is the subject and message clear and concise?
• [ X] Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• [ X] Does the commit contain a Signed-off-by: First Lastname [email protected]?
• [ X] Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• [ X] Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3697
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[rh-jhester]

After submitting this PR I noticed that the CPU that each process is running on is included in the output of the pidstat commands. We may want to include the stat files anyway--especially if we thought that the status files contained equivalent information--but the use case that prompted me to create the PR is technically invalidated.