Sysinternals is under Microsoft since 2006. Is this the ‘extend’ stage?
ProcMon for Linux (Preview)
31–40 of 45 posts
Re: ProcMon for Linux (Preview)
#32Why are libllvm6.0 llvm-6.0-dev and libclang-6.0-dev needed for this?
Re: ProcMon for Linux (Preview)
#33I never thought I'd say this, but: Thank you, Microsoft, for making useful, user-friendly software.
Re: ProcMon for Linux (Preview)
#34Why are libllvm6.0 llvm-6.0-dev and libclang-6.0-dev needed for this?
Seemingly because they download and build bcc as part of the build process. As to why they do that... probably because the three year old distro they're targeting has a three year old version of bcc.
Re: ProcMon for Linux (Preview)
#35I remember the first time I discovered Sysinternals tools for Windows.
It was a game-changer for me.
Especially Autoruns and Process Explorer
Re: ProcMon for Linux (Preview)
#36Earlier quoted context omitted.
Yes, ProcMon is the Windows equivalent of strace, with some filtering capability built-in. It also shows you the stack involved with a particular event, which can be useful for diagnosing the otherwise black box that is Windows. Eg [1] [1]: https://github.com/msys2/MSYS2-packages/issues/138#issuecomm...
The "filtering capability" actually makes up a good half of its worth. Being able to very quickly drill down to an annotated call stack for a specific IRQ on a specific file is really handy.
> call stack
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
Re: ProcMon for Linux (Preview)
#37Earlier quoted context omitted.
i always thought of the sysinternals tools as like the missing tools that just ship with unix systems. 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 th…
This was my reaction as well. 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…
Maybe I'm wrong, but I don't think htop can do things like: list every process which opened a certain file for read, how much bytes have been read at which offset in each case and how the threads stack frames locked like at the time. Then revert that filter and follow some hint to some other events, e.g. what network operations did a certain process do in a certain period of time.
Re: ProcMon for Linux (Preview)
#38Earlier quoted context omitted.
The "filtering capability" actually makes up a good half of its worth. Being able to very quickly drill down to an annotated call stack for a specific IRQ on a specific file is really handy.
> call stack 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
>> call stack
>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.
Re: ProcMon for Linux (Preview)
#39What are the differences between this and htop, by example? I know htop can strace processes with the "s" key.
This was my first thought, too. 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.
> 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?
Re: ProcMon for Linux (Preview)
#40I'm not familiar with the Windows version of ProcMon, but judging by the Linux version, that looks like it's primarily replicating the function of `strace` in a CLI GUI. Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
It's not quite strace, ProcMon also does network traffic stuff too. I used it quite a bit when my job was trying to shove proprietary (usually academic, usually engineering-related) software installers into a shape that we could make silently install. ProcMon was one of our first resorts whenever an installer would inevitably mysteriously crash when it ran inside an SCCM-managed installation of windows. Which. Was. O…
I do other sysadmin now but the job of getting whatever random vendor's installer into an SCCM deployable state required tools to see just WTF they were doing.
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.