9 ms·

You can use "-e trace=open" to trace only open(2) calls Alternatively "-e trace=%file" to get all file-related system calls (will catch eg failing pre-emptive

by zwp 3y ago

You can use "-e trace=open" to trace only open(2) calls Alternatively "-e trace=%file" to get all file-related system calls (will catch eg failing pre-emptive checks using access(3) -> stat(2)).

amelius 3y ago
Ok, but then you will still need to parse the output to get the filenames. That's ok, but since it is something that is used a lot, you'd expect a flag.
- tanelpoder 3y ago
  Check out strace -y and strace -yy (--decode-fds)
  - zwp 3y ago
    You still need to pull out the paths? A sprinkling of grep/perl (awk/sed/ruby/...) is mostly good enough eg: strace -e trace=%file cat /etc/passwd 2>&1 >/dev/null | grep ^open | grep -Po '(?<=").*(?=")'
- eesmith 3y ago
  Is your example situation really all that common? If so, what format do you expect for the output? If it's one filename-per-line then how do you encode filenames with embedded newlines? How do you encode non-UTF8 characters, or is the file meant to be parsed only in binary mode? I don't know of any generally agreed upon spec for this, so no matter what you think is right, most people are going to have to write a special-purpose parser. In which case you might as well parse the native strace output since one is about as complex as the other.
  - amelius 3y ago
    It can use the same format as the Unix find utility. This utility has a -print0 flag to separate filenames by NUL characters instead of newlines if desired.
    - eesmith 3y ago
      That is a good point. I still don't see it as common use case.
c0l0 3y ago
FTR, on modern-ish glibc-powered systems (in code that actually does use libc, and does not do its very own syscall-related thing instead), you will not find a single call to open(2) issued, in my experience. That's because the library functions shadowing these syscalls were rewired to use openat(2) under the hood. $ strace -e trace=open cat /dev/null +++ exited with 0 +++ $ strace -e trace=openat cat /dev/null openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/dev/null", O_RDONLY) = 3 +++ exited with 0 +++
- lelanthran 3y ago
  If you want to catch both `open` and `openat`, the opensnoop BPF[1] program is pretty nifty, especially if you are trying to figure out file stuff across several different programs ("which #$%^-ing program keeps modifying this file", for example). [1] I've been dipping my toes into BPF recently, and while complicated (best to simply clone the bpftools repo and work off of that) there's a lot that can be done that tools like strace won't be able to match.

by zwp 3y ago

You can use "-e trace=open" to trace only open(2) calls Alternatively "-e trace=%file" to get all file-related system calls (will catch eg failing pre-emptive checks using access(3) -> stat(2)).

amelius 3y ago

Ok, but then you will still need to parse the output to get the filenames. That's ok, but since it is something that is used a lot, you'd expect a flag.

tanelpoder 3y ago
Check out strace -y and strace -yy (--decode-fds)
- zwp 3y ago
  You still need to pull out the paths? A sprinkling of grep/perl (awk/sed/ruby/...) is mostly good enough eg: strace -e trace=%file cat /etc/passwd 2>&1 >/dev/null | grep ^open | grep -Po '(?<=").*(?=")'
eesmith 3y ago
Is your example situation really all that common? If so, what format do you expect for the output? If it's one filename-per-line then how do you encode filenames with embedded newlines? How do you encode non-UTF8 characters, or is the file meant to be parsed only in binary mode? I don't know of any generally agreed upon spec for this, so no matter what you think is right, most people are going to have to write a special-purpose parser. In which case you might as well parse the native strace output since one is about as complex as the other.
- amelius 3y ago
  It can use the same format as the Unix find utility. This utility has a -print0 flag to separate filenames by NUL characters instead of newlines if desired.
  - eesmith 3y ago
    That is a good point. I still don't see it as common use case.

c0l0 3y ago

FTR, on modern-ish glibc-powered systems (in code that actually does use libc, and does not do its very own syscall-related thing instead), you will not find a single call to open(2) issued, in my experience. That's because the library functions shadowing these syscalls were rewired to use openat(2) under the hood. $ strace -e trace=open cat /dev/null +++ exited with 0 +++ $ strace -e trace=openat cat /dev/null openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/dev/null", O_RDONLY) = 3 +++ exited with 0 +++

lelanthran 3y ago
If you want to catch both `open` and `openat`, the opensnoop BPF[1] program is pretty nifty, especially if you are trying to figure out file stuff across several different programs ("which #$%^-ing program keeps modifying this file", for example). [1] I've been dipping my toes into BPF recently, and while complicated (best to simply clone the bpftools repo and work off of that) there's a lot that can be done that tools like strace won't be able to match.