Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Difficulties of Tracking Running Processes on Linux (natanyellin.com)
39 points by nyellin on Aug 9, 2020 | hide | past | favorite | 10 comments


Is process accounting so obviously unsuitable to the article author's requirements, that it needs no mention at all?

https://unix.stackexchange.com/questions/468909/what-does-pr...


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.


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...


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.


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...


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.


Nice!

I find it ways more difficult debugging networking on Linux. It's easy to see which ports are in use but finding out which process is using a port is a nightmare to me.


Really? as previously mentioned, netstat and also lsof and fuser.


What about:

    sudo netstat -tnlp




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: