
The Difficulties of Tracking Running Processes on Linux - nyellin
https://natanyellin.com/posts/tracking-running-processes-on-linux/
======
kazinator
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...](https://unix.stackexchange.com/questions/468909/what-does-process-
accounting-mean-in-linux)

~~~
nyellin
I'm the author. I wasn't familiar with process accounting. Thanks for pointing
it out!

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

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

------
IvyMike
Worth mentioning the Microsoft(!) Process Monitor for Linux, as well.
[https://github.com/microsoft/ProcMon-for-
Linux](https://github.com/microsoft/ProcMon-for-Linux)

The windows procmon is very powerful, but the linux one is still in preview so
YMMV.

~~~
nyellin
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/tracer/ebpf/ebpf_tracer_engine.cpp#L76)

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

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

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

