| Summary: | gnome-settings-daemon deletes files underneath a mount point underneath /var/tmp/ | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eli Barzilay <eli> |
| Component: | gnome-settings-daemon | Assignee: | Rui Matos <tiagomatos> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | bnocera, fmuellner, johannbg, klember, lnykryn, mkasik, msekleta, muadda, ofourdan, rstrode, ssahani, s, systemd-maint, tiagomatos, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-12 10:15:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Eli Barzilay
2016-11-26 16:57:03 UTC
systemd-tmpfiles should stop at mount points. If it deleted stuff that was mounted as some subdirectory of /var/tmp, it could be one of reasons: 1. a pattern specifies that directory directly, so the mount check does not apply (e.g. you have something mounted as /var/tmp/foobar, and you added a custom rule D /var/tmp/foobar, or R /var/tmp/foo*, etc) 2. there's a bug in the implementation Do you have any custom patterns, or maybe some patterns from a package in the distribution that would match your mount point directly (case 1)? If not, can you run SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --clean and paste the output? (Don't put any important data there ;) ) 1. No, I don't have any custom rules that could have done that.
2. I tried running it a few times, and it all resulted in an expected
behavior, showing this as a result of the run:
Ignoring "/var/tmp/lambda": different filesystem.
3. While I was trying that with a toy directory with an old file, I
copied my whole home directory so I can do an experiment which is
even closer to the one I had originally done. This took a while
(more than 30m), and the toy mount was left connected during that
process -- by the time it was done, the *toy* old file was gone (from
the remote machine). Is it possible that there is some other cleanup
that would run? Or maybe systemd-tmpfiles runs differently when it's
on a schedule run?
systemd has two cleanup services: systemd-tmpfiles-setup.service is run during boot, and it runs systemd-tmpfiles --create --remove --boot systemd-tmpfiles-clean.service is started periodically, and it runs the command I gave. It's possible that something else could have removed those files. gnome-settings-daemon has a broken /tmp cleaner (broken in the sense that it doesn't implement what it promises, and it interferes with systemd-tmpfiles-clean because it bumps file access times). I'm not sure what it does when it encounters a mount point. I'm at a loss here. You might want to add two files: # /etc/systemd/system/systemd-tmpfiles-setup.service.d/50-debug.conf [Service] Environment=SYSTEMD_LOG_LEVEL=debug # /etc/systemd/system/systemd-tmpfiles-clean.service.d/50-debug.conf [Service] Environment=SYSTEMD_LOG_LEVEL=debug to turn debugging for those two services and see if what exactly happens when they run. Now that you say this, I remembered something interesting that I should have included earlier, which indicates that it might be something else. When I had my original problem occur, I re-copied the missing files from a backup, and then noted that the recovered files started to disappear too. When I had the above experiment done today, I saw that systemd-tmpfiles was avoiding removing files with a recent ctime, and I had to go through an extra hoop to generate a file with an old ctime. Unfortunately, I don't know if among the files that were originally removed there were ones that had a recent ctime but and old mtime/atime (since I was in panic mode; it's a live machine), but given the above I think that it is. In any case, I now have a mount of my mirrored home, with a shell loop that will start beeping when the total du changes. Hopefully it'll happen again when I can catch it. And less than 10 seconds after I send that reply, my shell thing started
beeping! Looking around, there was indeed a suspiciously active
gnome-settings-daemon -- I straced it in htop and indeed I saw a bunch
of unlink()s. I would have pasted that, but htop doesn't have an easy
way to copy text, and by the time I started a command-line strace, it
had already stopped removing files.
Also, it looks like it's doing something weird, as if it has some stale
cache or something, since the (g-s-d) process now polls paths like:
/home/eli/gvfsd-fuse
/home/eli/selinuxfs
/home/eli/lambda:
The last name in the above is making me extra worried, since I have a
"lambda" symlink to an sshfs mount (the mount that used to be in
/var/tmp and now I moved it to /mnt).
I'll leave the strace running in case something interesting comes up,
but this is definitely the offender that deletes the mounted files.
Following this:
https://bbs.archlinux.org/viewtopic.php?id=170122
I verified that gnome-settings-daemon is indeed the offender by creating a file
and just hitting the "Purge Temporary Files" button. Bug submitted here:
https://bugzilla.gnome.org/show_bug.cgi?id=775301
But IMO (obviously) this is important enough for RH to do something about it
ASAP.
s/RH/Fedora/. Please note that Fedora is not Red Hat, and not only Red Hat people work on Fedora. Sorry about the confusion. TBH, should really s/RH/whoever uses this thing/... If I had the energy, I'd post it everywhere... Thanks! This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |