Could well be. If I recall correctly the motivation behind the porting was to give their engineers a unified set of tooling for troubleshooting windows and Linux (on Azure). I just assumed that the porting efforts would result in a similar set of tools to use locally on the box.
Not taking anything away from the worth of this tool but if you do happen to find yourself needing to quickly inspect which files a process has open you can do so using the /proc file system:
ls -l /proc/$PID/fd/
Additionally you can also use the /proc file system to display where the cursor is in those files by outputting the contents of
/proc/$PID/fdinfo/$FD
which is handy if you have a long running process but forgot to pipe it into `pv` (or any other long running ingest that lacks a progress UI)
It is available for Linux however it's not always part of the base install of every distribution (but a worthwhile install none-the-less).
Not taking anything away from lsof as I do use it myself but I do also think there is also merit in learning the /proc file system too because it helps illuminate some of the not-so-hidden magic behind Linux. Even if you then still find lsof or similar become your preferred utility.
biotop and biolatency surface similar info. they come with a ton of other ridiculously awesome tools in BCC tools. they are a set of python wrapper scripts that run eBPF programs. using eBPF generally has a really low impact on performance when compared with other tools that do similar work.
I see that you are using ptrace to monitor a process. That is also used by strace. Is there something else your application does that strace does not (In relation to files)?
I have strace'd whatfiles, in fact that was a very useful way to debug a couple things, so maybe? I have not been able to attach to the same process with both whatfiles and strace, however.
BTW, if you are using strace for this, check out the -y option recently added to strace. It will print the filename next to each file descriptor like this:
read(3</proc/filesystems>, "", 1024) = 0
Another interesting new strace option is -k which does a stack dump after each syscall. this can be useful to find out what part of the application, like some obscure lib, does weird system calls in your app.
37 comments
[ 2.7 ms ] story [ 77.6 ms ] threadhttps://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-12...
https://mspoweruser.com/microsoft-working-on-sysinternals-fo...
Maybe that is where the porting effort went.
https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-12...
This traces file events of a single process. Strace can be coaxed into something similar.
(Both tricks are Linux only)
Edit: By monitoring things, I mean like finding how far through a dd is after you have started it already.
ls -al /proc/$PID/fd/ | wc -l
Useful for actually knowing what that specific process has open and is respecting your Max Open Files settings.
I'm looking at you Influx.
Not taking anything away from lsof as I do use it myself but I do also think there is also merit in learning the /proc file system too because it helps illuminate some of the not-so-hidden magic behind Linux. Even if you then still find lsof or similar become your preferred utility.
https://github.com/iovisor/bcc
https://github.com/iovisor/bcc/blob/master/tools/opensnoop_e...
`strace -e trace=file`
I see that you are using ptrace to monitor a process. That is also used by strace. Is there something else your application does that strace does not (In relation to files)?
> Isn't this just a reimplementation of strace -fe trace=creat,open,openat,unlink,unlinkat ./program?
> Yes. Though it aims to be simpler and more user friendly.
https://aur.archlinux.org/packages/whatfiles-git/
edit: fatrace is system-wide, whereas the current tools monitors a specific process
http://manpages.ubuntu.com/manpages/trusty/man1/fatrace.1.ht...
https://piware.de/2012/02/fatrace-report-system-wide-file-ac...
Because strace on Linux still fails with:
in those cases :(