Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #270097 > unrolled thread

Re: Re: Having ten thousands of mount bind causes various processes to go into loops

Back to article view | Back to linux.debian.user

Contents

  Re: Re: Having ten thousands of mount bind causes various processes  to go into loops Julien Petit <julien@nethik.fr> - 2024-06-14 11:50 +0200
    Re: Having ten thousands of mount bind causes various processes to  go into loops Toni Mas Soler <antomassol@gmail.com> - 2024-06-14 17:50 +0200
    Re: Having ten thousands of mount bind causes various processes to go  into loops Max Nikulin <manikulin@gmail.com> - 2024-06-15 14:40 +0200

#270097 — Re: Re: Having ten thousands of mount bind causes various processes to go into loops

> What processes are CPU hungry?

On a vanilla debian 11 : udisksd, gvfs-udisks2-vo, (fstrim), find

> Perhaps it is not a Debian-specific bug, just more active usage of sandboxing in systemd. If some applications have troubles parsing /proc/mounts then bugs should be filed against them.

It seems to happen with all processes accessing mounts. And since
disabling sandboxing with php fixed the problem for the php process,
it looks like it is linked to sandboxing.

> However do you need shared subtrees? It may cause exponential growth of number of moutpoints, see

We only use mount bind to share an initial folder with other users
with different access rights (rw or ro). So we probably don't need
shared subtrees (as long as mount bind doesn't rely on it). I'm not
really familiar with subtrees though. In my understanding, it is used
for chroot or containers and that's something we don't use. When i
list our mounts, it seems they are by default in shared mode. If the
default before was "private", it might be why it used to work and it
stopped.
I'm gonna test the effect of setting them to private.

Thanks for your help

[toc] | [next] | [standalone]

#270101 — Re: Having ten thousands of mount bind causes various processes to go into loops

El Fri, 14 Jun 2024 11:30:50 +0200
Julien Petit <julien@nethik.fr> va escriure el següent:

> > What processes are CPU hungry?  
> 
> On a vanilla debian 11 : udisksd, gvfs-udisks2-vo, (fstrim), find
> 
> > Perhaps it is not a Debian-specific bug, just more active usage of
> > sandboxing in systemd. If some applications have troubles parsing
> > /proc/mounts then bugs should be filed against them.  
> 
> It seems to happen with all processes accessing mounts. And since
> disabling sandboxing with php fixed the problem for the php process,
> it looks like it is linked to sandboxing.
> 
> > However do you need shared subtrees? It may cause exponential
> > growth of number of moutpoints, see  
> 
> We only use mount bind to share an initial folder with other users
> with different access rights (rw or ro). So we probably don't need
> shared subtrees (as long as mount bind doesn't rely on it). I'm not
> really familiar with subtrees though. In my understanding, it is used
> for chroot or containers and that's something we don't use. When i
> list our mounts, it seems they are by default in shared mode. If the
> default before was "private", it might be why it used to work and it
> stopped.
> I'm gonna test the effect of setting them to private.
> 
> Thanks for your help
> 

Just to learn about it.
What about using acl rather than bind mounts? What should be the
problem in this solution?

Thanks.

[toc] | [prev] | [next] | [standalone]

#270107 — Re: Having ten thousands of mount bind causes various processes to go into loops

On 14/06/2024 16:30, Julien Petit wrote:
>> What processes are CPU hungry?
[...]
> udisksd,

This one does not use mount namespace for the obvious reason. However it 
tends to generate unnecessary activity. Perhaps it needs optimizations 
for your case.

> (fstrim)

There were some bugs including sandboxing setting in its unit file, but 
perhaps it is irrelevant.

> find

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.

> It seems to happen with all processes accessing mounts. And since
> disabling sandboxing with php fixed the problem for the php process,
> it looks like it is linked to sandboxing.

 From my point of view PHP is more complex than find.

> We only use mount bind to share an initial folder with other users
> with different access rights (rw or ro).

I have not figured out from your description what problem you solved by 
using bind mounts, but bublewrap (so flatpak and snap) and firejail 
relies on bind mounts as well. Perhaps you have some unique factors.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web