On 19/06/2024 16:27, Julien Petit wrote:
Does it have some logic to avoid descending into bind mounts? Maybe I am
wrong with my expectation that it does not use anything besides st_dev
from stat result. It may be promising case to demonstrate the issue in a
way independent of systemd and sandboxing. You can obtain command line
arguments. Attach to its mount namespace and inspect content of its
/proc/<PID>/mounts or mountinfo. The next step would be to profile or at
least to trace a process.
I'm not sure i understand you there.
It was intended to express my surprise that "find" is affected. I may
expect some bugs in udisksd or PHP related to number of entries in
"mounts" or "mountinfo" /proc files, but find is much more simple and
likely more convenient for debugging of the issue. (Actually I am even
more surprised by presence of udisksd on a cloud platform with sharing
files among virtual users.)
On 20/06/2024 04:18, Julien Petit wrote:
However do you need shared subtrees?
I'm gonna test the effect of setting them to private.
This doesn't seem to fix the problem either
Sorry, but without any details what you have actually tried, it adds
nothing to the following kind of summary: "Despite there are enough
projects that actively use bind mounts, some person faced some obscure
issue. The tool might be used in a wrong way".
User and mount namespaces caused some challenges in respect to bind
mounts. Personally I have not convinced that changes in kernel may
contain some regression. However nowadays bind mounts perhaps should be
treated with more care.
It seems nobody on this list is motivated enough to actively participate
in debugging starting from the script you posted. You may ask in other
communities.
