Hello, Am Samstag, 17. Februar 2018, 03:43:37 CET schrieb Jim Henderson:
On Fri, 16 Feb 2018 20:04:51 -0500, Patrick Shanahan wrote:
* Jim Henderson <hendersj@gmail.com> [02-16-18 19:28]:
[zypper ps shows /var/lib/gdm/.config/dconf/user was deleted, and is still opened by several processes running as user "gdm"]
What I'm saying is that this happened:
1. I ran zypper up. 2. I ran zypper ps -s 3. Processes using deleted files showed up. 4. I stopped the graphical interface. 5. zypper ps -s showed the deleted files were no longer in use 6. I started the graphical interface. 7. zypper ps -s showed the deleted files were once again in use 8. I decided with the other btrfs issue that I reported here, that I would reboot the system. 9. After a full system reboot and starting back into the graphical interface, the deleted files that were in use were still somehow in use. After a reboot.
Without checking the code, I'm quite sure that the gdm processes open /var/lib/gdm/.config/dconf/user and then instantly delete it (while keeping the file open). This means the file becomes "invisible" on the filesystem, but still exists and is usable for the processes that have it open. Actually at this stage the file only gets unlinked (it no longer has a filename, and isn't visible in directory listings), but still exists on the filesystem. When the file gets closed, the disk space finally gets freed. Besides the obvious disadvantage of causing confusion, this has a few advantages that might make it attractive for developers to use this way: - automatic cleanup - as soon as the file gets closed (or the process that opened it crashes), the file gets finally removed / the disk space gets freed on the filesystem. - no other process can read or modify the file (that's not entirely true because it's still available as /proc/$pid/fd/$number - but at least that makes it harder to access a deleted file) I'll give you a short demo: #!/bin/bash tempfile="$(mktemp)" || { echo 'mktemp failure'; exit 1; } echo 'foo bar baz' > "$tempfile" cat "$tempfile" | while read line ; do ls -l "$tempfile" rm -v "$tempfile" echo $line done cat opens $tempfile and keeps it open. In the first run of the loop $tempfile gets deleted, but cat still has an open filehandle on it and can successfully read the file content of the deleted file. The script (intentionally) prints some error messages for rm and ls (when the file no longer exists), but between them, you'll see that it prints out foo, bar and baz.
I've been doing Linux for a while - and updating zypper with doing a proper system restart for years now - and ran 42.2 on one system with btrfs for the entire life of 42.2 without any issues.
I'm completely stumped as to two things here:
1. Why 'snapper cleanup number' is throwing a quota error after it worked once, even though (as I understand it) quotas are disabled by default (and I have tried turning quotas off and back on again with no effect)
2. Why even after a reboot, various gdm-owned processes open deleted files instead of using the new files the way it's supposed to work. My assumption here is that something is hosed in a btrfs subvolume and these processes are accessing files from an earlier snapshot (or something along those lines).
I don't have an answer for your btrfs issues, but I'm sure it's unrelated to the gdm using deleted files.
By definition, if a file is deleted, a new process can't open the inode.
Right, but the new process can create a new file, open it, and then delete it.
It doesn't seem to *harm* the system (for now), but I'm tempted to reinstall again. I'd rather not do that - I'd rather understand what happened so I can prevent it from happening again, and if I've run into a defect, I'd like to report it so it can get fixed.
I hope the above makes it clear what happens - if not, feel free to ask again. Regards, Christian Boltz -- <cboltz> jjohansen: we can just label it "the can't be more broken than 2.8.3 release" ;-) <sbeattie> cboltz: I'm disappointed in your inability to believe that I can't screw things up further. [from #apparmor] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org