Re: Re: Having ten thousands of mount bind causes various processes to go into loops
> This can be solved with ACLs. Instead of creating a bind mount, this process > that allows the user to share the directory can set an ACL and create a > symlink. For a few users maybe but not that easy when you have many thousands users (that on top do not have local accounts). We'd probably hit another ACL limitation. Then again, this thread was not about finding new ways of doing what we do but to know the reason it stopped working. Is it a new limitation or a bug? > PS: It would be better if you used a mailer that correctly sets mail headers > References and/or In-Reply-To so that your replies are properly threaded. Sorry about that, i use the link provided on the list for mails i don't receive in my mailbox directly and gmail doesn't seem to be good about it...
Re: Having ten thousands of mount bind causes various processes to go into loops
> PS: if you maintain your own software and aren't able to find a way for your > user to do shares - especially while systems that most likely have such > functionality built-in out of the box surely exist, think Nextcloud etc - > that is covered by how Linux is supposed to be used, by definition it's > pretty much out of support. Nextcloud doesn't offer sftp or rsync access to users that i know of. The specifications are much simpler because they only deal with web access (the web interface and the webdav server written in PHP). How Linux is supposed to be used? That's why i'm here. There wasn't until kernel 4.19 an official limit to the number of mounts in the documentation. Even though we use mounts a lot, we're still far from the official limit. Did we get lucky for 15 years and we should change the way we do things or is it a bug ? I will now take this to the kernel team and see what they have to say about it. > Especially if you keep insisting on using a way that was never officially > supported, just because you got away with it for 15 years. That's the very question i guess! How much mount is too much mount ;) Thanks again for your help.
Re: Having ten thousands of mount bind causes various processes to go into loops
> At this point, I kinda doubt this issue has anything to do with Debian > itself, but will most likely be an issue/limitation of the Linux Kernel > itself. >From my latest tests, it seems to point that way. Kernel 5.4 came with a new mount API and it seems to break since then. During my search, i also found that since kernel 4.19, there is a default limit of mount set to 100 000 to avoid DOS. We're still far from it.
Re: Having ten thousands of mount bind causes various processes to go into loops
> For this, probably the easiest is to set up a common directory/a few common > directories, set up proper permissions through use of groups and worst case > create some symlinks from the user's home directories, if these directories > really need to be accessible from within their home directories. That's > pretty much how shared directories are always done. As this would be a one > time effort, it would be doable. You're thinking of a traditional file server in a business. Our solution is a cloud platform. We don't know ahead how our customers are going to manage their files and shares. And we don't need to. As i said to Eduardo, it doesn't really matter where folders/mounts are. Users can share any directory (and subdirectories) in their home directory with any other user. The shared folder is mounted in the special directory "Shared with me" of the recipient home directory. I.e: John/Sales/Invoices is mounted in Alice/Shared with me/Invoices. The shares can be read/write or read-only. > But at this point, you should really think about paying some company with > deep knowledge of Linux that can come up with a sustainable plan. Because > obviously, your way of doing things isn't anything that could (or on that > note should) be a long-term solution. And maybe think about rewriting the > ancient software that causes this setup in the first place. We've come up with that solution in 2009 and it's been working until now (and still is but eating away cpus). So i guess it makes it a proven long-term solution ;) Is there a better way to do it now? Maybe. But not as easy as setting up a few symlinks and some permissions. Anyway, that's out of subject. My request is simpler than knowing how our solution works. Mounting many thousands folders wasn't an issue before and it is now (i haven't nailed on which Debian update it broke yet). As i said in my request, i know that this usage is an heavy usage of mounts but it worked perfectly for many years. I'm just trying to understand the cause behind it. > Desperately trying to cling to something that has been out of support for > decades is just not sustainable, not on any OS. We're the maintainers of our software so it's not out of support :) I'm here because we'd like to save a few trees reducing that cpu usage down :D Thanks again for your time!
Re: Re: Having ten thousands of mount bind causes various processes to go into loops
> Does it really have to be in the home directory? Can't the software (and/or > the users) open files in, say, /shared/accounting? It doesn't really matter where folders/mounts are. Users can share any directory (and subdirectories) in their home directory with any other user. The shared folder is mounted in the special directory "Shared with me" of the recipient home directory. I.e: John/Sales/Invoices is mounted in Alice/Shared with me/Invoices. > If it really needs to be under /home: symlinks. Symlinks are no good since the user sharing his directory can decide to share it read/write to one user but read only to another
Re: Re: Having ten thousands of mount bind causes various processes to go into loops
>> 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
Re: Having ten thousands of mount bind causes various processes to go into loops
> 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//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. > 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. Mounts are used as a way of sharing folders in different users' home directories. For instance you would have : /users/bob/accounting shared with Alice and accessible in her home directory /users/alice/accounting Thanks for your help :)
Re: Having ten thousands of mount bind causes various processes to go into loops
> Just to learn about it. > What about using acl rather than bind mounts? What should be the > problem in this solution? As i said to Richard, rights are not the challenge here. It's to be able to share a directory across multiple users. For instance you would have : /users/bob/accounting shared with Alice and accessible in her home directory /users/alice/accounting
Re: Having ten thousands of mount bind causes various processes to go into loops
> If there's a better way should be judged on what exactly that app expects. > For the web interface, maybe the http server - or whatever makes the web > interface accessible to the users - can limit permissions. For the rest of > the use cases it would be interesting which circumstances would need to be > fulfilled for a user to be able to change permissions on a file they own. And > if they could even change the permissions through sftp, webdav or rsync. > Because if not, the simplest fix would be a cron job that peridoically sets > the permissions on the directory, so you don't need a dedicated mount. But > Maybe you want to create a separate topic where you describe exatcly what the > basic requirements are and ask for suggestions what the best solution may be. > Maybe something like AppArmor rules or other methods that aren't known by > your typical user could be a better solution. Rights are not the challenge here. It's to be able to share a directory across multiple users. For instance you would have : /users/bob/accounting shared with Alice and accessible in her home directory /users/alice/accounting > If you haven't already, remember to create a bug report and include as much > detail and logs as you can gather, as people will need to be able to tell > what the actual issue is. Maybe it's a limitation of the file system, of the > hardware or something else. I haven't already. I want to test the using private mounts first. Thanks again for your input.
Re: Having ten thousands of mount bind causes various processes to go into loops
> Best question probably is: what exactly are you needing 14.000 mounts for? > Even snaps shouldn't be that ridiculous. So what's your use case? Maybe > there's a better solution to what you are doing. If it's just about having a > place that is rw only without execution permissions, just crate a separate > partition, mount it somewhere - e.g. /home/test/mounts and tell mount/fstab > to use the option noexec. No need for for your script. Or if it's a more > advanced file system like btrfs you may be able to simply create a subvolume > with the same capabilities, no need to tinker around with partitions. We use the mounts to share an initial folder with either rw or ro wrights in a user directory. The user directory is then accessible through a web interface, sftp, webdav and rsync. There is probably better ways to do that now but that's a legacy app (2009) that we'd rather leave alone :) > It's true this issue should be looked into, but it doesn't look urgent as > long as there are alternatives. Yes, not urgent and very specific. I'm going to try to set the mounts to private as Max suggested and see how it goes. Thanks for your help.
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
Having ten thousands of mount bind causes various processes to go into loops
Dear,
Not sure i should report a bug so here is a report first. For more
than 10 years now, we've been using mount binds to create shares rw or
ro. It's been working perfectly under older Debian. A few months ago,
we migrated to Ubuntu Jammy and started having processes running 100%
non stop. While examining the processes in question, we could see the
same thing: it seemed to be reading all the mounts indefinitely.
It started with the phpsessionclean.service. We managed to fix it
editing /lib/systemd/system/phpsessionclean.service and disabling
sandboxing entries. But then it started to happen with other
processes.
Anything related to systemd seems affected in a way. For instance, we
cannot start haproxy if the mounts are mounted.
We tested with the last Debian and it is affected too.
We understand that 14 000 mounts is a lot. So maybe our usage will be
questioned. But this has been working for ages so why not now?
The problem can be very easily reproduced:
1. Launch the latest Debian stable
2. Execute the following script to create mounts:
#!/bin/bash
mkdir /home/test/directories
mkdir /home/test/mounts
for i in {1..14000}
do
echo "Mounting dir $i"
mkdir "/home/test/directories/dir_$i"
mkdir "/home/test/mounts/dir_$i"
mount --bind -o rw "/home/test/directories/dir_$i" "/home/test/mounts/dir_$i"
done
After that, the "top" command will show processes getting stuck using
100% of CPU never ending.
Has anyone a clue if this is fixable? Should i report a bug?
Thanks for your help.
elle marche plus la list debian??
_ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp
Re: Re: APT-GET et les répértoires d'install
Merci à tous pour les infos _ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp
Apache 1.3 ou apache 2?
Salut, j'aimerais savoir quelle version il faut mieux utiliser pour un serveur? Et de la même manière si je n'utilise pas apt-get pour l'installer et plutot la methode traditionnelle, est-ce que ca risque de me poser des problèmes par la suite? Par exemple pour des patchs de sécurité ? Je suis newbie mais pour le moment je préfère compiler moi même les applis, j'ai l'impression de plus controler l'install, est-ce que je me trompe? Dernière petite question, pour une recompilation, suffit-il de telecharger les sources du nouveau paquet, de faire un ./configure . make et make install? Si y'a deja une version faut-il pas avant supprimer des fichiers / desinstaller?? Merci encore _ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp
Re: Re: Apache 1.3 ou apache 2?
Tout d'abord merci, comme tu dis je préfererais m'habituer au fonctionnement du apt-get, ca m'eviterais de perdre du temps a chercher des correctifs pour les bugs de sécurité. Mais ce qui m'embrouille avec apt c'est que je ne sais jamais quoi installer comme paquet et dans quel ordre. Par exemple en compilant j'ai les sources de mysql, d'apache et de php. Je les compile dans cette ordre, et c'est finit. Pour les paquets debian, j'ai mysql-server, mysql-client, apache, php4-mysql Je sais jamais ce qu'il faut que j'installe et dans quel ordre. Y'a t-il un how-to pour ca? De plus je suppose que lorsqu'on installe avec apt-get, par la suite il suffit de faire un apt-get upgrade pour mettre a jour la distrib, mais j'ai un peu peur de ce upgrade, je ne sais pas ce qu'il fait, si il touche a mes fichiers de config, si il faut reparametrer tout a chaque fois ... _ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp
Re: Re: Apache 1.3 ou apache 2?
Encore une ptite chose sur apt-get. Les paquets disponible sur debian.org pour la version stable sont toujours en retard par rapport aux sources que l'on peut trouver sur les sites officiels. Par exemple pour mysql on en est a la version 4.0.20 stable sur mysql.com et a la 3.23 pour les paquets deb. Ca pose pas de problème de sécurité? Si on veut etre super a jour on peut, il faut peut-être mieux compiler certaines applis soi-même? _ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp
APT-GET et les répértoires d'install
Bonjour tout le monde, est-il possible lorsque je fais un apt-get install apache par exemple, de spécifier le répértoire d'installation? Du type ./configure --prefix=/usr/local/apache Je ne vois rien dans la doc apt-get Et y'a t'il une commande pour savoir d'avance ou va être installé le package? Merci d'avance _ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp
