GNOME Bugzilla – Bug 730587
gnome-keyring-daemon failing on sshfs
Last modified: 2021-04-11 07:49:41 UTC
Created attachment 276996 [details] multiple temp files generated Use whatever local installation you want, e.g. an ubuntu live cd killall gnome-keyring-daemon cd ~/.gnome2 mv keyrings keyrings.old mkdir keyrings keyrings.new chmod 700 keyrings keyrings.new sshfs localhost:/home/username/.gnome2/keyrings.new keyrings gnome-keyring-daemon -s -f With those commands, you're running gnome-keyring-daemon using sshfs for keyrings This causes the gnome-keyring-daemon to hang, while simultaneously creating thousands of *temp* files in the new keyrings folder. This is a blocker for users which have a mounted home folder via SSHFS. (LTSP on Ubuntu 14.04) https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1321922
Could someone please confirm this? It is still an issue.
I can confirm this on Ubuntu 14.04. The problem seems to be somewhere in ./pkcs11/gkm/gkm-transaction.c, function begin_link_temporary_if_exists().
I'm also seeing this on Ubuntu 14.04.
I'm see it now (LTSP Fat Client) on Ubuntu 14.04
I am doing a migrate of my users home folders now. Thousands of temp keyrings in each user's home folder. quite a mess to clean up.
This affects me as well, I've got over 100 users, many who have this problem, creating many 10's of thousands of these files.
Created attachment 311684 [details] ncdu screen shot showing over 120K files After further investigation I'd say I've got millions--not 10's of thousands--of these files. I'm also using LTSP Fat Clients on Ubuntu 14.04, am also using AD binding with pbis 8.3.
In LTSP, we had to `chmod -x gnome-keyring-daemon` for all versions after 3.10, to prevent gnome-keyring from filling up our disks with temp files and crashing our systems. http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2673 Could some gnome developer at least stop the loop there, so that it doesn't retry forever, creating millions of temp files?
I can confirm that this affects openSUSE as well.
Still no fix for the gnome-keyring with ltsp clients... this make cloud connections to Contacts, Nautilus, Evolution impossible. No workaround except preventing the daemon to execute?
@Werner Koch, @Stef Walter: I located the exact commit that caused this issue, it's this one authored/committed by you: https://git.gnome.org/browse/gnome-keyring/commit/?id=7f31eebd35a84ed4c09970edb0b8d99a6a8af6f5 Provide fallback for file systems without working hardlinks My test case was done on Ubuntu 16.04, gnome-keyring 3.18.3-0ubuntu2. $HOME/.local/share/keyrings (the new path where the keyrings are stored) was mounted over SSHFS. 1) I launched seahorse and tried to create a new keyring, named "qwer". Thousand of "qwer.keyring.temp-999800304" were being created. I had to run `killall -9 gnome-keyring-daemon` to regain control. 2) I reverted pkcs11/gkm/gkm-transaction.c right before the commit that caused the regression: https://git.gnome.org/browse/gnome-keyring/tree/pkcs11/gkm/gkm-transaction.c?id=dff0a6edd2c02602b24476296855b4f63f99379f https://git.gnome.org/browse/gnome-keyring/log/?ofs=300 2012-08-09 Add MATE Desktop to desktop files raveit65 4 -4/+4 I launched gnome-keyring-daemon again, I tried to create a new keyring and everything worked fine. Problem solved. 3) I moved on to the problematic commit: https://git.gnome.org/browse/gnome-keyring/commit/?id=7f31eebd35a84ed4c09970edb0b8d99a6a8af6f5 2012-08-09 Provide fallback for file systems without working hardlinks Werner Koch 1 -11/+135 It was affected, proving that this is the commit that caused the issue. Could you please comment on if you plan to fix or revert that regression? It's prohibiting thousands of installations from upgrading to newer Gnome versions, so your input will be much appreciated. Thank you!
Mounting the keyrings directory over sshfs isn't something that was in mind when writing gnome-keyring-daemon. I'm not against it though. So if you do have a fix/patch to make gnome-keyring-daemon work on sshfs I'd gladly review it. I would suggest also adding a test case to the test suite so this (corner case) doesn't break again in the future.
Alkis prepared a system to test this. The reason that this is failing is because sshfs in shitty with regards to hard links. But it has the exact opposite problem as Werner ... the link succeeds, but then it fails to report the number of links, and also fails to report inodes correctly. So the copy_to_temp_file() fails because the destination exists, and was just created by the link(). Werner, do you remember if EMC CIFS would return success in link() without actually creating a link?
Good to see you are on to it and making progress! Thanks for that.
Any progress on this? It has been many years but it's still an issue. My diskless clients mount /home over sshfs. gnome-keyring-daemon: 3.20.1 SSHFS version 3.3.1 FUSE library version 3.2.0 using FUSE kernel interface version 7.26 fusermount3 version: 3.2.0
Hi Stef, since Werner hasn't replied for 4 years, could you please at least stop the loop, as it creates 65000 temp files and delays the login process for 2 minutes before giving up?
Alkis, Are you up for making a patch for this and submitting it to GNOME GitLab? Thanks! https://wiki.gnome.org/Newcomers/SubmitContribution
Stef thank you for the proposal, I'm more of a shell/python coder nowadays, if noone more experienced with C has the time to submit a patch, I'll give it a try after GSoC (in September).
Debian/GNOME 10 and Ubuntu 18.04 are also affected. I disabled GNOME keyring by: dpkg-divert --divert /usr/bin/gnome-keyring-daemon.bak --rename /usr/bin/gnome-keyring-daemon Any progress on this bug would be appreciated.
Same with Gentoo Linux and Mate. Please help!
Superseded by https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/84