On Fri, 16 Feb 2018 20:04:51 -0500, Patrick Shanahan wrote:
* Jim Henderson <hendersj@gmail.com> [02-16-18 19:28]:
On Fri, 16 Feb 2018 23:59:02 +0000, Jim Henderson wrote:
On Sat, 17 Feb 2018 00:28:36 +0100, Christian Boltz wrote:
Maybe the listed processes create a tempfile and instantly delete it (while keeping it open and therefore useable for the process that opened it).
Please check with zypper ps (without the -s) to see the filenames of the deleted files used by these processes.
Thanks, Christian. The good news is that after rebooting into recovery, I ran a btrfs check; it didn't find any issues, but the issue with zypper ps -s showing in-use files seems to have cleared up. It was really strange that that issue persisted through a reboot earlier this week.
Well, it came back after running another zypper up.
The files shown are:
jhenderson@lamuella:~> sudo zypper ps The following running processes use deleted files:
PID | PPID | UID | User | Command | Service | Files ------+-------+-----+------+----------------------+--------- +-------------------------------- 18849 | 18838 | 478 | gdm | gnome-session-binary | | /var/lib/ gdm/.config/dconf/user 18860 | 1 | 478 | gdm | at-spi-bus-launcher | | /var/lib/ gdm/.config/dconf/user 19023 | 1 | 478 | gdm | goa-daemon | | /var/lib/ gdm/.config/dconf/user 19041 | 1 | 478 | gdm | mission-control-5 | | /var/lib/ gdm/.config/dconf/user
processes using deleted files are processes that continue running after you update those file with zypper. when you reboot, you clear the processes and they restart using the newly installed files rather than the deleted/replaced/upgraded files.
you will only notice running processes using deleted files after and update.
you do not need to reboot to clear the subject processes. many you can kill and restart, also restarting the graphic target will clear some. usually the only time a reboot is necessary is for a kernel update or a dbus (messagebus) update.
some knowledge of the particular processes is necessary to determine the proper procedure to clear it w/o rebooting.
Thanks, Patrick - I am aware of this, but I do appreciate your jumping in to help try to sort out what's going on. This isn't my first Linux rodeo (been running openSUSE and its predecessors since 2003, and Linux since the late 90s - used to build my own kernels back in the day). 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. 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). btrfs check doesn't show any problems. Nothing is logged that I can find. The only symptoms I see are the quota error running a snapper cleanup number and after running zypper up, these gdm-owned processes continue to use deleted files when they start up - even after a reboot. I'm totally stumped. I've tried rebuilding the qgroups, I've tried disabling quotas entirely, I've grepped through dmesg and journalctl outputs until I'm blue in the face. Nothing is actually getting me additional info about what's going on in this filesystem. Nothing appears corrupt to the tools, but the behaviour is like nothing I've ever seen in ~20 years of running Linux. By definition, if a file is deleted, a new process can't open the inode. Yet that's exactly what's happening here. I terminate the processes with an 'init 3', and zypper ps says no deleted files are in use. I run 'init 5' to switch back to the GUI, and the deleted files are *reopened*. I reboot the machine, and the deleted files are *reopened*. How does that happen? And does it have anything to do with the other weirdness in the filesystem that's causing snapper to not allow me to run a cleanup command - but only for the 'number' snapshots. I can delete those snapshots individually without a problem. Then I run zypper up, new snapshots are created, and the same behaviour returns - deleted files in use, stop the process, deleted files not in use. Start the process again, deleted files are *again* in use. Reboot the system - deleted files are *again* in use. 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. Sorry for the long-winded answer. I'm just totally baffled about what's going on here. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org