So it just prints "get the target path of link foo" instead of "readlink(foo)" and so on?
When I read the description I hoped it would match broad strokes like "load library foo.so" but the screenshot shows that it just rewords each syscall name into English.
Yeah, it seems like it could be implemented as a postprocessor of strace --decode-fds. Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored (e.g. collecting /etc/localtime) and which are explicitly requested by the application, piecing together multi-threaded/multi-process logic, etc. strace has a lot of functions to help with that which this doesn't support, like syscall filtering, struct decoding, and stack tracing.
Agreed, I'm a bit underwhelmed by intentrace when compared to the richness of strace. For sure, strace could maybe benefit from some UX like colorised output and a TUI that lets you filter syscalls while it is running.
>Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored
An excellent point!
More broadly, since many/most Linux/Unix/etc, programs use one or more libraries (which in turn could use one or more other libraries, etc., etc.), then one very important key for designers of any type of strace program, present or future, is:
Can the traced system calls be set granularly, such that the individual libraries making syscalls (as opposed to the main program!) be identified individually, and possibly filtered in/out from the results accordingly?
Huh, I did not realize I was settling for something so incomprehensible compared to this. Really nice to see. Maybe there are other nice tools like this?
> Strace for Everyone
For a moment there I was excited to see strace on the Mac. Not for everyone, it seems.
To be fair, we do have fs_usage and, if you disable SIP, dtrace. fs_usage is nowhere near as awesome and comprehensive as strace, but it's something.
Yes, I get by with dtruss which is inferior to strace but usually good enough. It's just a 1000 line dtrace program so I guess it could be improved.
So it just prints "get the target path of link foo" instead of "readlink(foo)" and so on?
When I read the description I hoped it would match broad strokes like "load library foo.so" but the screenshot shows that it just rewords each syscall name into English.
Yeah, it seems like it could be implemented as a postprocessor of strace --decode-fds. Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored (e.g. collecting /etc/localtime) and which are explicitly requested by the application, piecing together multi-threaded/multi-process logic, etc. strace has a lot of functions to help with that which this doesn't support, like syscall filtering, struct decoding, and stack tracing.
Agreed, I'm a bit underwhelmed by intentrace when compared to the richness of strace. For sure, strace could maybe benefit from some UX like colorised output and a TUI that lets you filter syscalls while it is running.
Mmmm: https://github.com/xfgusta/strace-with-colors
>Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored
An excellent point!
More broadly, since many/most Linux/Unix/etc, programs use one or more libraries (which in turn could use one or more other libraries, etc., etc.), then one very important key for designers of any type of strace program, present or future, is:
Can the traced system calls be set granularly, such that the individual libraries making syscalls (as opposed to the main program!) be identified individually, and possibly filtered in/out from the results accordingly?
So, an excellent point!
[dead]
Huh, I did not realize I was settling for something so incomprehensible compared to this. Really nice to see. Maybe there are other nice tools like this?
A better traceroute is mtr - was mentioned a few days ago on here.
tcptraceroute can also be more useful sometimes, as it doesn't rely on ICMP for the probes. But mtr all the way.
eBPF has entered the chat: https://github.com/iovisor/bcc
https://www.youtube.com/watch?v=Wb_vD3XZYOA
[dead]