El Fri, 14 Jun 2024 11:30:50 +0200 Julien Petit <jul...@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.
