ProcMon for Linux (Preview)(github.com) |
ProcMon for Linux (Preview)(github.com) |
without them, there was no real visibility into open file descriptors, network ports, command lines for running processes, thread trees for processes or any of the rest.
the gui was always just the windows way of presenting it. bringing a gui when the rich tools already exist on linux seems ... redundant?
(seeing this brings back nightmares from windows admins who refused to install sysinternals tools on production machines)
I haven't used Process Monitor/Process Explorer for a while, are they bringing anything to the table that's not covered by htop? With htop, I can even start tracing a process (using strace) or list the file opened by a process (using lsof) right inside htop. As might be obvious by now, I think htop has a fantastic TUI that also fits its use case very well.
Of course there are other tools that allow deep introspection into what's really going on aside from htop. Another favorite of mine would be perf top, which uses the sampling profiling mechanism to profile the entire system (including the kernel) on a symbol/instruction level. In other words, you don't just see that 30% of CPU time is spent in /usr/bin/cpu_hog, you also see that the time is spent in some_symbol and you can jump right in and see disassemble some_symbol (as long as cpu_hog is not stripped).
Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
Sorry, it's been over a decade now and I still have nightmares sometimes. But yeah procmon is cool.
I recall one .exe installer, unzipping to an MSI, which installed the program files but then ran .bat file to run three separate driver installers for the associated hardware. And I had to get it all working in AppV.
I don't use Procmon much now as my work has changed, but I still consider it a good friend.
I am glad linux has other ways to do it but as a linux noob, I'd try procmon first if I had to.
[1]: https://github.com/msys2/MSYS2-packages/issues/138#issuecomm...
Presumably it isn't, and the README should list the actual requirements (kernel versions, etc.), with a note to the effect of "packages are available for Ubuntu LTS releases since 18.04".
I am odysseas, DevRel at Netdata. I would love to hear your story and what Netdata helped you diagnose in your systems.
Hit me up (odyslam) in our forums: https://community.netdata.cloud
I know htop can strace processes with the "s" key.
Which useful feature does this tool have what htop does not have?
Let's say there is such a feature. Why did they not implement it in htop? Made a patch and offered it to upstream? This is why we have FOSS. To benefit from each other's work.
This is why so much open source software is crap and without any structure.
Htop is very different from proc on. Integrating proc on into Htop would make zero sense. Why would you suggest this would be a good idea without knowing what the software does?
Bug report: https://github.com/Sysinternals/ProcMon-for-Linux/issues/44
This looks like an amazing tool, can't wait to begin using it.
Hmmm... didn't know it could do that.
This file says it does, though only for network events: https://documentation.help/Process-Monitor/documentation.pdf
strace -k
> specific IRQ
IRQs are very low level and can't be traced by strace or procmon. both can easily log specific syscalls, e.g. strace -e. strace can't quite filter on ioctl, but apparently procmon can't trace ioctl at all: https://stackoverflow.com/questions/9947933/how-to-log-the-d..., so strace is ahead there.
> specific file
strace -P path
>strace -k
>> specific file
>strace -P path
That strace can do it too is fine and all, but the Windows ProcMon collects a trace that you can then filter, like Wireshark. So it enables a workflow where you have no idea what's going on, collect a trace, and discover what entry to focus on and what paths to filter for. (This is what I demonstrated in the msys issue link I posted.)
An equivalent workflow is possible with strace too of course; pipe `strace` to a file and then discover what paths you want to grep for. It does become a bit noisy when the stack of every syscall is included, and requires more complicated grepping because it spans multiple lines, so you might have to first pre-process it into something structured like JSON.