Today, a sort of race condition happened, where systemd mounted temporarily:
ramfs on /run/credentials/systemd-tmpfiles-clean.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
which led to a p@ging alert on es1036: with /run/credentials/systemd-tmpfiles-clean.service is not accessible: Permission denied
I have never seen this false positive happen on databases, but it seems that the right fix is to ignore ramfs types from the check, as we are usually only interested on ext4, xfs and maybe other "real" filesystems mounted. In particular, even df ignores by default all "dummy, duplicate, or inaccessible file systems, which are omitted by default. Dummy file systems are typically special purpose pseudo file systems such as ‘/proc’, with no associated storage."
I don't know why this particular instance failed, maybe because it was temporary there is a non-atomic "listing -> umount -> check" that leads to a race condition? But that wouldn't make sense, it wouldn't have failed 3 times in a row. Maybe the cleaning of temporary files lasted more time than usual?
