The Difficulties of Tracking Running Processes on Linux(natanyellin.com)
natanyellin.com
The Difficulties of Tracking Running Processes on Linux
https://natanyellin.com/posts/tracking-running-processes-on-linux/
11 comments
I'm the author. I wasn't familiar with process accounting. Thanks for pointing it out!
I don't know the applications, but it may well not be suitable (providing the command path, for instance). I feel the pain of this from working on an HPC resource manager and more generally wanting to track executions on the system for management purposes.
I didn't need them when using Irix, so I don't know if it would have addressed the actual issue, but that seems to have had better facilities, such as easily-usable robust process trees. Similarly Super-UX, it seemed.
I didn't need them when using Irix, so I don't know if it would have addressed the actual issue, but that seems to have had better facilities, such as easily-usable robust process trees. Similarly Super-UX, it seemed.
To really capture any new process, on an x86 chip at least, you'd need to implement some kind of hardware callback to the OS whenever a new Task State Segment (TSS) was created in the GDT.
Note however, that this wouldn't capture new threads that are created inside of existing tasks/processes, nor those inside of software emulated virtual machines, and the capture of those, additionally, for logging purposes, might be desirable...
But, for future hardware designers out there -- if you're going to create a new CPU, then I think a hardware callback for anytime a new task is created -- would be a great addition for your new CPU...
Perhaps such a callback could be done in microcode...
Also, this callback should work in all nested VM/protection levels, from the highest level hypervisor, down to the lowest level OS...
Anyway, just thinking aloud...
Note however, that this wouldn't capture new threads that are created inside of existing tasks/processes, nor those inside of software emulated virtual machines, and the capture of those, additionally, for logging purposes, might be desirable...
But, for future hardware designers out there -- if you're going to create a new CPU, then I think a hardware callback for anytime a new task is created -- would be a great addition for your new CPU...
Perhaps such a callback could be done in microcode...
Also, this callback should work in all nested VM/protection levels, from the highest level hypervisor, down to the lowest level OS...
Anyway, just thinking aloud...
Worth mentioning the Microsoft(!) Process Monitor for Linux, as well. https://github.com/microsoft/ProcMon-for-Linux
The windows procmon is very powerful, but the linux one is still in preview so YMMV.
The windows procmon is very powerful, but the linux one is still in preview so YMMV.
Under the hood that uses eBPF handlers for the sys_enter and sys_exit tracepoints
https://github.com/microsoft/ProcMon-for-Linux/blob/main/src...
https://github.com/microsoft/ProcMon-for-Linux/blob/main/src...
I wrote an eBPF security monitoring tool for an endpoint protection solution that is surprisingly similar to your proposed solution of walking the dentry tree for obtaining the command path.
It basically takes a block of memory, and splits it in a static array of arrays, and then walks the dentry tree, copying each portion of the path into it.
It then follows and decodes the mount path in a similar way, and it's fully recomposed in user space into a single path.
I could have done the mount path in userspace too probably by just passing some identifier.
It basically takes a block of memory, and splits it in a static array of arrays, and then walks the dentry tree, copying each portion of the path into it.
It then follows and decodes the mount path in a similar way, and it's fully recomposed in user space into a single path.
I could have done the mount path in userspace too probably by just passing some identifier.
https://unix.stackexchange.com/questions/468909/what-does-pr...