Hi folks,
I have a problem with Gnome-Keyrings, my filesystem seems to be flooded by millions of *.keyring.temp-* files in directory .gnome2/keyrings.
I have a home server (CentOS 8) where the files are located. On my workstation (Fedora 33 XFCE Spin) I mount it via autofs and sshfs into the /home-Directory.
I do not have a good understanding of what Gnome Keyrings does, but in my eyes I have a "standard" installation, I can' t remember that I did something that brought it onto my workstation, I expect that Gnome Keyring was already there after the initial installation of the workstation. Because the file system on the workstation is mounted from a server my problem might be caused by any restrictions on the server (i.e. SELinux or whatever), but because it is mounted via sshfs I expect that the server is "innocent" as far as an ssh from the workstation to the server works. For that reason I post to the Fedora mailing list.
I did some investigation that shows, that at probably random points in time each time 64999 temp files are create in .gnome2/keyrings, so after some minutes I have millions of files there. Following my analysis.
Workstation:
The OS version is
cat /etc/redhat-release Fedora release 33 (Thirty Three)
and just for completeness, but probably not important, the XFCE version is
xfce4-about -V xfce4-about 4.14.1 (Xfce 4.14) ...
SSH from workstation to server works fine
ssh sysadmin@server3 "ls -d ~/disk1/home_meikel" /home/sysadmin/disk1/home_meikel
and the file system is mounted
LANG="" df -h /home/meikel Filesystem Size Used Avail Use% Mounted on sysadmin@server3:/home/sysadmin/disk1/home_meikel/ 1007G 747G 210G 79% /home/meikel
After some minutes/hours of working on the workstation the directory .gnome2/keyrings/ seems to be flooded by hundred of thousands of temp files, the directory listing takes about one and a half minute (!!!):
cd /home/meikel
time ls -l .gnome2/keyrings/ | wc -l 247263
real 1m28,358s user 0m4,642s sys 0m3,831s
Home-Server (via ssh):
The OS version is
cat /etc/redhat-release CentOS Linux release 8.4.2105
After some time (this example was taken during the same day, some hours later) the situation is the same, meanwhile there are some millions of temp files:
cd /home/sysadmin/disk1/home_meikel/.gnome2/keyrings/
time ls -l | wc -l 2804719
real 0m49,023s user 0m27,330s sys 0m22,120s
Further investigation:
To understand what are those millions of files I did a
ls -l .gnome2/keyrings/ > /tmp/gnome-keyrings-3.txt
and some further manually investigation. Following I give the beginning of /tmp/gnome-keyrings-3.txt where I manually replaced multiple occurrences of the same line by "--> xxx times". There seems to be a pattern where in each point of time it tries for 64999 times to create a temp file:
total 10438868 -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 20:39 Trousseau_de_clés_par_défaut_9.keyring.temp-1000041255 -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 20:39 --> 64997 times -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 20:39 Trousseau_de_clés_par_défaut_9.keyring.temp-1000072888
-rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:35 Trousseau_de_clés_par_défaut_9.keyring.temp-100000967 -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:35 --> 64997 times -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:35 Trousseau_de_clés_par_défaut_9.keyring.temp-1000037381
-rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:32 Trousseau_de_clés_par_défaut_9.keyring.temp-1000014039 -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:32 --> 64997 times -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 19:32 Trousseau_de_clés_par_défaut_9.keyring.temp-1000058050
-rw-------. 64999 sysadmin sysadmin 1162 Jun 5 18:42 Trousseau_de_clés_par_défaut_9.keyring.temp-1000006582 -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 18:42 --> 64997 times -rw-------. 64999 sysadmin sysadmin 1162 Jun 5 18:42 Trousseau_de_clés_par_défaut_9.keyring.temp-1000149586
... many more ...
The word "Trousseau_de_clés_par_défaut" (it is french) means something like "default keyring". To find a pattern in the timestamps to understand when those temp files are created I ran
cut -c 42-53 gnome-keyrings-3.txt | sort | uniq Jun 2 07:28 ... Jun 5 10:52 ... May 22 08:12 ... May 28 08:35
but due to the "sort" the result is now unsorted (!!!), there is a break in the sorting between June and May. I' m not sure if I really need to sort before uniq-ify the output. As it' s a result of "ls -l" it might already be sorted by timestamp. However I need a further step to sort output by timestamp, so I ran
cut -c 42-53 gnome-keyrings-3.txt | sort | uniq | while read d ; do date +%s -d "${d}" ; done | sort | while read d ; do date -d @${d} ; done sam. 22 mai 2021 08:12:00 CEST sam. 22 mai 2021 08:21:00 CEST sam. 22 mai 2021 13:45:00 CEST dim. 23 mai 2021 09:18:00 CEST mar. 25 mai 2021 07:44:00 CEST mar. 25 mai 2021 07:59:00 CEST mar. 25 mai 2021 08:06:00 CEST mer. 26 mai 2021 07:43:00 CEST jeu. 27 mai 2021 07:45:00 CEST jeu. 27 mai 2021 08:22:00 CEST ven. 28 mai 2021 08:34:00 CEST ven. 28 mai 2021 08:35:00 CEST mer. 02 juin 2021 07:28:00 CEST mer. 02 juin 2021 07:31:00 CEST mer. 02 juin 2021 07:42:00 CEST mer. 02 juin 2021 07:47:00 CEST mer. 02 juin 2021 07:49:00 CEST sam. 05 juin 2021 10:52:00 CEST sam. 05 juin 2021 10:56:00 CEST sam. 05 juin 2021 10:57:00 CEST sam. 05 juin 2021 11:00:00 CEST sam. 05 juin 2021 11:04:00 CEST sam. 05 juin 2021 11:07:00 CEST sam. 05 juin 2021 11:11:00 CEST sam. 05 juin 2021 11:14:00 CEST sam. 05 juin 2021 11:19:00 CEST sam. 05 juin 2021 11:22:00 CEST sam. 05 juin 2021 11:28:00 CEST sam. 05 juin 2021 11:32:00 CEST sam. 05 juin 2021 11:40:00 CEST sam. 05 juin 2021 11:43:00 CEST sam. 05 juin 2021 11:53:00 CEST sam. 05 juin 2021 11:56:00 CEST sam. 05 juin 2021 12:09:00 CEST sam. 05 juin 2021 12:12:00 CEST sam. 05 juin 2021 12:27:00 CEST sam. 05 juin 2021 12:30:00 CEST sam. 05 juin 2021 12:47:00 CEST sam. 05 juin 2021 12:50:00 CEST sam. 05 juin 2021 13:11:00 CEST sam. 05 juin 2021 13:14:00 CEST sam. 05 juin 2021 13:38:00 CEST sam. 05 juin 2021 13:41:00 CEST sam. 05 juin 2021 14:09:00 CEST sam. 05 juin 2021 14:12:00 CEST sam. 05 juin 2021 14:40:00 CEST sam. 05 juin 2021 14:43:00 CEST sam. 05 juin 2021 15:22:00 CEST sam. 05 juin 2021 15:25:00 CEST sam. 05 juin 2021 16:01:00 CEST sam. 05 juin 2021 16:04:00 CEST sam. 05 juin 2021 16:49:00 CEST sam. 05 juin 2021 16:51:00 CEST sam. 05 juin 2021 17:41:00 CEST sam. 05 juin 2021 17:44:00 CEST sam. 05 juin 2021 18:38:00 CEST sam. 05 juin 2021 18:42:00 CEST sam. 05 juin 2021 19:32:00 CEST sam. 05 juin 2021 19:35:00 CEST sam. 05 juin 2021 20:39:00 CEST
So at each of these timestamps the number of 64999 temp files is created in .gnome2/keyrings. I can't see any pattern in those points of time, I don't understand for what reason there need to be created the temp files at theses times and why always 64999 times at the same moment. From time to time I manually delete the files by running (as root)
find . -name "*.temp-*" -delete
which is not really satisfying. Any ideas what is the reason that these millions of temp files are created? Why do I need Gnome Keyrings? Can I get rid of that software to solve the problem?
Regards,
Meikel
On 09/06/2021 00:44, Meikel wrote:
I have a problem with Gnome-Keyrings, my filesystem seems to be flooded by millions of *.keyring.temp-* files in directory .gnome2/keyrings.
I have a home server (CentOS 8) where the files are located. On my workstation (Fedora 33 XFCE Spin) I mount it via autofs and sshfs into the /home-Directory.
No suggestions as of yet. Just a few questions.
Your home directory on the Fedora system is being automounted via sshfs from a CentOS system. Yes?
Your home directory on the Fedora system is /home/meikel. Yes?
Your user name on the Fedora system is sysadmin and primary group is also sysadmin?
On Jun 8, 2021, at 12:45, Meikel meikel@fn.de wrote:
I have a home server (CentOS 8) where the files are located. On my workstation (Fedora 33 XFCE Spin) I mount it via autofs and sshfs into the /home-Directory.
The problem is caused by your sshfs homedir and gnome-keyring:
https://bugzilla.gnome.org/show_bug.cgi?id=730587
It is a rather old bug, and it doesn’t seem likely that it’ll be fixed any time soon. Basically, if you have a fuse mounted sshfs home directory, you can’t use gnome-keyring.
— Jonathan Billings
On 6/8/21 4:19 PM, Jonathan Billings wrote:
It is a rather old bug, and it doesn’t seem likely that it’ll be fixed any time soon. Basically, if you have a fuse mounted sshfs home directory, you can’t use gnome-keyring.
Why would you want to do that? That sounds a whole lot of problems waiting to happen, besides being really slow.
On Tue, Jun 08, 2021 at 05:40:11PM -0700, Samuel Sieb wrote:
On 6/8/21 4:19 PM, Jonathan Billings wrote:
It is a rather old bug, and it doesn’t seem likely that it’ll be fixed any time soon. Basically, if you have a fuse mounted sshfs home directory, you can’t use gnome-keyring.
Why would you want to do that? That sounds a whole lot of problems waiting to happen, besides being really slow.
sshfs and autofs are a simple way to set up network home directories without having to build any infrastructure other than an SSH server and some storage on a remote system. It uses FUSE, so it only supports a subset of the POSIX filesystem functions.
No one wants to support network filesystems anymore, I guess. BTW, AFS still works great for network home directories, and Fedora has an AFS client baked into the kernel. Works with gnome-keyring too. :) I've been trying to also get SMB3 to work well for $HOME, but its not there yet.
Am 09.06.2021 um 00:35 schrieb Ed Greshko:
Your home directory on the Fedora system is being automounted via sshfs from a CentOS system. Yes?
Yes.
Your home directory on the Fedora system is /home/meikel. Yes?
Yes.
Your user name on the Fedora system is sysadmin and primary group is also sysadmin?
Nope.
Fedora /home/meikel user=meikel group=meikel Centos /home/sysadmin/disk1/home_meikel user=sysadmin group=sysadmin
I could create user:group=meikel:meikel on CentOS 8 if required, but as sysadmin:sysadmin was already there I thought I can use that user.
Am 09.06.2021 um 15:27 schrieb Jonathan Billings:
On Tue, Jun 08, 2021 at 05:40:11PM -0700, Samuel Sieb wrote:
Why would you want to do that? That sounds a whole lot of problems waiting to happen, besides being really slow.
sshfs and autofs are a simple way to set up network home directories without having to build any infrastructure other than an SSH server
Thats exactly the reason why I did this configuration. The ssh server was already there and I did not have do install or configure anything on the server (which was not already installed or configured).
Am 09.06.2021 um 01:19 schrieb Jonathan Billings:
The problem is caused by your sshfs homedir and gnome-keyring:
https://bugzilla.gnome.org/show_bug.cgi?id=730587 https://bugzilla.gnome.org/show_bug.cgi?id=730587
It is a rather old bug, and it doesn’t seem likely that it’ll be fixed any time soon. Basically, if you have a fuse mounted sshfs home directory, you can’t use gnome-keyring.
This explains the problem sufficently for me. I need to decide if I can get rid of gnome-keyrings and if not then I have to get rid of sshfs-mounted home directory.
Thanks.
On Wed, Jun 09, 2021 at 05:10:58PM +0200, Meikel wrote:
Am 09.06.2021 um 01:19 schrieb Jonathan Billings:
The problem is caused by your sshfs homedir and gnome-keyring:
https://bugzilla.gnome.org/show_bug.cgi?id=730587 https://bugzilla.gnome.org/show_bug.cgi?id=730587
It is a rather old bug, and it doesn’t seem likely that it’ll be fixed any time soon. Basically, if you have a fuse mounted sshfs home directory, you can’t use gnome-keyring.
This explains the problem sufficently for me. I need to decide if I can get rid of gnome-keyrings and if not then I have to get rid of sshfs-mounted home directory.
So, I've worked with some network filesystems that behave poorly with certain daemons, and one of the solutions I've used was to have a login process copy the data into $XDG_RUNTIME_DIR (i.e. /run/user/$UID) and then point the daemon there. Of course, you need a cleanup process that copies it back (or syncronizes it periodically).
It's nice that GNOME's dconf has figured this out already, and you can set "service-db:keyfile/user" in /etc/dconf/profile/user instead of "user-db:user", that makes dconf copy the user's config into XDG_RUNTIME_DIR and then periodically sync it back to $HOME as a text file. I suspect you might get some mileage out of that if you use sshfs.
If you're familiar with windows, it would be like Folder Redirection and Roaming Profiles.
Semi-off-topic: I actually started working on a user daemon that does the sync for a configurable set of directories/files in $HOME, so you could, for example, create a tmpfs for $HOME and sync files from a network homedir. Why do this? Because that network homedir might not support things like hard links, sockets, fifos, or just be really slow. The idea would be to set XDG_CONFIG_HOME at the slow network filesystem, and other XDG_ variables, as described here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html One idea I had was that you could even use this with services like Dropbox (with a proper encryption layer in front of it). Use something like rclone's autofs support: https://github.com/rclone/rclone/wiki/rclone-mount-helper-script ... or just sync directly using the native sync client or the provider.
Ed Greshko:
Your user name on the Fedora system is sysadmin and primary group is also sysadmin?
Meikel:
Nope.
Fedora /home/meikel user=meikel group=meikel Centos /home/sysadmin/disk1/home_meikel user=sysadmin group=sysadmin
I could create user:group=meikel:meikel on CentOS 8 if required, but as sysadmin:sysadmin was already there I thought I can use that user.
As a general rule, it's easier to do networked storage (and debugging is far more straightforward), when users are the same user on both sides of the network.
I have a NAS device which seems to go to great pains to make every file on it owned by one user, yet make all the networked traffic go through some bizarro SMB handler to filter ownership. If you want to use NFS in a traditional manner, you have to keep SSHing in and chown user's directories back to themselves any time it reboots. About the only other workaround is to put all your files in the public directories where everyone can do anything with them.
-
Ed Greshko -
Jonathan Billings -
Meikel -
Samuel Sieb -
Tim