Access to HDD shows fine, but access to rootfs (on SDcard / ramdisk) shows open_by_handle_at: Too many levels of symbolic links

[porg]

Environment

• fatrace 0.16.2-2 (installed via apt)
• Open Media Vault 6 (based on Debian 11)
  • On an Odroid Home Cloud 2 (SBC: 32-bit CPU + SD card + SATA HDD)
  • Using https://www.armbian.com/odroid-xu4/
  • Armbian 22.05.3 Bullseye with Linux 5.4.199-odroidxu4

Reproduction

• ✅ Access to the HDD on my NAS shows fine in fatrace
• ❌ But the few times I go to the Web UI of OpenMediaVault and persists some setting changes,
• this is when it seemingly accesses its rootFS, and then I get some of these lines in fatrace:
  open_by_handle_at: Too many levels of symbolic links

Investigation / Thoughts

• The system uses folder2ram to avoid write amplification on the SD card
  • Maybe that is involved in the symbolic link redirections which happen?
• In open_by_handle_at: Too many levels of symbolic links #2 you transformed that limitation from being fatal to informal.
  • Would it be possible to get at least some information (e.g. the first filepath that was attempted to be accessed, before the symbolic link redirection, which then fails) ** instead of just having no info at all**?
  • The file event type letter O / R / W / D could get a suffix like → so e.g. R→ to indicate this is not the final destination but the symbolic link which was attempted to be accessed

[martinpitt]

get at least some information (e.g. the first filepath that was attempted to be accessed

No, because this is exactly the first step in determining the file path. At this point fatrace has not the slightest idea what the changed fd refers to.

That error message corresponds to ELOOP, and the manpage says

ELOOP handle refers to a symbolic link, but O_PATH was not specified in flags.

and

If handle refers to a symbolic link, the caller must specify the O_PATH flag, and the symbolic link is not dereferenced; the O_NOFOLLOW flag, if specified, is ignored.

I already have a symlink check in the tests. I played around with some ln -s, mv, touch etc. scenarios, but so far could not reproduce such an issue. Then again, the only thing that I need that fd for is to fstat() it, and to get the fd number to read /proc/pid/fd, so O_PATH is actually sufficient.

I added a commit which uses O_PATH. Can you please try latest master and see if that fixes this? If not, I'm happy to reopen.

[porg]

I'm at maximum a scripter, tinkerer. But no developer.

• I'd appreciate somehow dummy save build instructions in the README.md
• Then I sure would love to give it a try.

[martinpitt]

See #20 (comment) for a current master binary.

[porg]

✅ Also works now when running my build of af3ebbd with no manual changes (just ran make)

As ME I did this:

$ cd /    # Note: Cd-ing to "/" to the use --current-mount
$ sudo ~/bin/bin/fatrace/fatrace --current-mount

• 👍 No more: open_by_handle_at: Too many levels of symbolic links
• 👍 Now shows all kind of file events, by all kind of users, a very busy festival 😉 going on here :

A lot going on within just a fraction of a second

mountpoint(26905): C   /etc/ld.so.cache
mountpoint(26904): O   /usr/lib/locale/C.UTF-8/LC_NAME
...

bash(24579): CWO /home/me/test-tmpfs-me.txt
bash(24579): CWO /home/me/test-tmpfs-me.txt
...
... yes, that's ME firing inbetween in another window
..

smbd(14752): O   /etc/ld.so.cache
smbd(14752): C   /etc/ld.so.cache
...

nginx(1495): O   /var/www/openmediavault/index.html
nginx(1495): R   /var/www/openmediavault/index.html
nginx(1495): C   /var/www/openmediavault/index.html
...

monit(26907): O   /usr/bin/mountpoint
monit(26907): R   /usr/bin/mountpoint
monit(26907): R   /usr/bin/mountpoint
...

mountpoint(26907): O   /usr/lib/arm-linux-gnueabihf/ld-2.31.so
mountpoint(26907): R   /usr/lib/arm-linux-gnueabihf/ld-2.31.so
mountpoint(26907): O   /etc/ld.so.cache
...

cron(26909): O   /etc/pam.d/cron
cron(26909): R   /etc/pam.d/cron
cron(26909): O   /etc/pam.d/common-auth
cron(26909): R   /etc/pam.d/common-auth
cron(26909): RO  /usr/lib/arm-linux-gnueabihf/security/pam_unix.so
cron(26909): O   /etc/ld.so.cache
cron(26909): RO  /usr/lib/arm-linux-gnueabihf/libcrypt.so.1.1.0
...

omv-ionice(26911): RCO /usr/sbin/omv-ionice
omv-ionice(26911): RO  /usr/bin/dash
...

pgrep(26912): O   /etc/ld.so.cache
pgrep(26912): RO  /usr/lib/arm-linux-gnueabihf/libprocps.so.8.0.3
...

unknown(26913): RO  /usr/bin/ionice
unknown(26913): RO  /usr/lib/arm-linux-gnueabihf/ld-2.31.so
unknown(26913): CO  /etc/ld.so.cache
unknown(26913): RO  /usr/lib/arm-linux-gnueabihf/libc-2.31.so
unknown(26913): O   /usr/lib/locale/locale-archive
...

[porg]

Needing to cd away from your pwd elsewhere in order to use --current-mount is a unhandy way to change scope, as this use case showed again. Because if you need something from your current directory, e.g. the local built fatrace as in this example, you need to reference back to your previous pwd. Not very handy.

A use case where it would be nice to be able to stay were you are and call fatrace with --scope /path/to/device #18