Exploring procfs
In summary, all linux's processes can be found in /proc
folder. This folder is of procfs type which, like I said before, is a virtual filesystem and most of its file descriptors point to in-memory data. This is why if you run a ls /proc -l
you'll notice that most files and folders are of size 0.
1 | ls -l /proc |
Inside '/proc' there is one folder for each process running with its pid as name. So I opened one of the folders to see what I could learn about a running process just by reading these filed.
1 | ls -l /proc/<pid> |
Ok, now I have a bunch of files like autogroup
, gid_map
and maps
that I have no idea what they're for. A good starting point would be checking for their documentation. But why on earth shouldn't I just open them?
So I started looping through the files one by one and most of them were completely unreadable for me, until I ran into the golden pot:
1 | cat /proc/<pid>/status |
This is great! Finally something human readable. It contains general data about the process, like its state, memory usage and owner. But is this all I need?
Not satisfied with '/proc' file exploration, I decided to run ps
against strace
to see if it's accessing any of the files I found.
1 | strace -o ./strace_log ps aux |
Strace returns all system calls executed by a program. So I filter strace result by 'open' system call and as I suspected (maybe I didn't) the files being open by operating system were the same I first checked:
1 | cat ./strace_log | grep open |
Ok, so we have stat
, status
and cmdline
files to check, now all we need to do is to parse this and extract what we need.
The code
The implementation turned out to be fairly simple and it comes down to reading files and display its content in an organized matter.
Process data structure
We want to display our data in a tabular way; where each process is a record on this table. Let's take the following class as one of our table records:
1 | class ProcessData |
Finding Pid's for running processes
Take into account what we know so far:
/proc
folder contains sub-folders with all processes- All process folders have their pid as name
So gathering a list of all current pids should be easy:
1 | def get_current_pids |
In order to be a valid process folder it must fulfill two requirements:
- It's a folder (duh?)
- It's name contains only number (this is why we have to cast folder name to int)
1 | def is_process_folder? folder |
Extracting process data
Now that we know every pid in the system we should create a method that exposes data from /proc/<pid>/status
for any of them.
But first, lets analyze the file.
1 | cat /proc/<pid>/status |
This file is organized in the following way: Key:\t[values]
. This means that for every piece of data in this file we can follow this same pattern to extract it. However, some lines will have an individual value and others will have a list of values (like Uid
)
1 | def get_process_data pid |
The method above results in the following structure:
1 | get_process_data 2917 |
Reading user data
User uid
and name association is kept in /etc/passwd
file, so in order to show the correct username we must also read this file and parse it.
For the sake of simplicity, let's just read the whole file and save it in a Hash
with key as Uid
and value as name.
1 | def get_users |
Creating process records
So far we have found the pids
in the system, read the status
file and extracted the data. What we have to do now is to filter and organize this data into a single record that will be presented to the user.
1 | current_processes = filesystem.get_current_pids |
The reason why we get VMRss
value is because we want to check resident memory values, this means, only what's stored in the physical memory and not what's sitting in our disk.
Extra (formatting)
You can format ProcessData text in a tabular way to get a prettier output.
1 | format="%6s\t%-15s\t%-10s\t%-10s\t%-10s\n" |
Result:
1 | PID NAME USER STATE MEMORY |
Conclusion
There is a lot of information that you can find under /proc
folder. This post only covers basic data like name, state and resident memory. But if you dig deep into those files you will find a lot more, like memory mapping and CPU usage.