GNOME Bugzilla – Bug 737079
housekeeping-plugin starts spewing "Too many open files" and deletes random files from my home directory
Last modified: 2014-09-22 16:08:33 UTC
First, how do I prevent this piece of crap from running again and deleting my whole life? It has occurred for me before that lots of random files and directories in my home directory have disappeared, but I had not established a direct link until now. The first thing I noticed was some intense hard drive activity -- usually most of my stuff runs off SSD, so that's quite unusual. I launched a terminal window to see what's going on and zsh greets me with a message saying that my .zshrc file is missing. So I immediately power off the computer. After starting it up again, as happened before, there are lots of files missing and my logs have many messages like: Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /var/tmp/systemd-private-08a6f11550884d5aac4bbb3afe119ae9-colord.service-SCfFLk: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /var/tmp/systemd-private-08a6f11550884d5aac4bbb3afe119ae9-ntpd.service-R41Yjy: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/.esd-120: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/systemd-private-08a6f11550884d5aac4bbb3afe119ae9-colord.service-B5vd6z: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/systemd-private-08a6f11550884d5aac4bbb3afe119ae9-ntpd.service-QXktVS: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/atop.d: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp1/lost+found: Permission denied Sep 21 18:23:26 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp1/.lesshst: No such file or directory Sep 21 18:23:27 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp1/.amarok: No such file or directory Sep 21 18:23:27 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp0/.amarok: No such file or directory Sep 21 18:23:27 host gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp0/.lesshst: No such file or directory I have GNOME 3.12 with gnome-settings-daemon 3.12.2, running on Arch Linux.
Sorry, that was the beginning of the log file with "Permission denied" and "No such file or directory" errors. But most messages actually state "Too many open files", like: Sep 21 18:23:31 newn gnome-session[955]: (gnome-settings-daemon:987): housekeeping-plugin-WARNING **: Failed to enumerate children of /tmp/mp0/src/util-linux/.git/objects: Too many open files
Are you sure it's the housekeeping plugin? That will only delete ~/.cache, and only if so configured. What looks like instead is that you have valuable data in /tmp (mount points perhaps?), and systemd-tmpfiles is cleaning it up. Arguably not checking for mount points is a systemd bug, but it is also partially your problem for abusing /tmp instead of /mnt or /media. In any case, if you still believe the culprit is in gnome-settings-daemon, you can disable the plugin with gsettings set org.gnome.settings-daemon.plugins.housekeeping active false Also, please refrain from defining software "a piece of crap". I understand that losing valuable personal data is infuriating, but such language only causes hostility and is less likely to convince a developer into looking at your problem.
> Are you sure it's the housekeeping plugin? That will only delete ~/.cache, and > only if so configured. Not 100% sure, but I think I have good reasons to suspect it: 1. There's a piece of software capable of recursively scanning directories and deleting files. 2. There are log messages of this software malfunctioning (running out of file descriptors). 3. There is evidence of it scanning outside of ~/.cache 4. The timing of disappearance of files correlates highly with these error messages. If housekeeping only cleans up ~/.cache then how do you explain the error messages about /tmp? Sadly my logs don't go far back enough, but I think I've also seen similar log messages for $HOME, but at the time I didn't suspect anything yet. Is there a way to invoke housekeeping directly from shell so I could strace it or something? > What looks like instead is that you have valuable data > in /tmp (mount points perhaps?), and systemd-tmpfiles is cleaning it up. Those are read-only mountpoints (backups of my home directory to restore some files) and I didn't lose any data from there. I have been losing data in /home/marti and filesystems symlinked from there. The disappeared data was always writable to my user, no data from other users has been touched. If it were something system-wide like systemd-tmpfiles, I presume it would affect all users the same. > gsettings set org.gnome.settings-daemon.plugins.housekeeping active false Thanks!
This sounds like bug 730223 which is fixed in the 3.12 branch but we never did a release after that. Sorry for that. I've released 3.12.3 now, you might want to ask your distro to udpate the package. If the bug isn't fixed yet please re-open this. *** This bug has been marked as a duplicate of bug 730223 ***