Bug 975521
Summary: | unable to change settings using dconf | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matus Marhefka <mmarhefk> | ||||||
Component: | dconf | Assignee: | Matthias Clasen <mclasen> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 19 | CC: | awilliam, dan.mashal, dominick.grift, dwalsh, emmanuel.pacaud, esandeen, fedora, jbastian, kparal, mclasen, mgrepl, mmarhefk, pschindl, rhughes, robatino, rth, satellitgo, stefano, tflink, tomkarger, walters | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | AcceptedBlocker | ||||||||
Fixed In Version: | glib2-2.36.3-2.fc19 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2013-06-23 06:25:29 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: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 834090 | ||||||||
Attachments: |
|
Description
Matus Marhefka
2013-06-18 16:53:12 UTC
Hi, I've tried to downgraded dconf to 0.15.3, but it didn't fix the issue. Proposing as a final blocker: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use". You are using dconf-editor? I can't reproduce this on a simple install / boot installed system / try and reproduce / install updates / reboot / try and reproduce cycle on a live image, but it would be good to look into various recent reports of dconf issues more closely before dismissing this. dan: no, the bug seems to be that the user's dconf database gets corrupted somehow; after that, any action at all which requires updating the database will fail (and on the next boot, the user's settings will probably fail to load). We noticed this with MATE when a user ran emcas as root, permissions in .config got screwed up. See IRC if you're around. Just noticed this on TC5 .xsession-errors: (mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header (mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header ** Message: applet now removed from the notification area (In reply to Adam Williamson from comment #5) > dan: no, the bug seems to be that the user's dconf database gets corrupted > somehow; after that, any action at all which requires updating the database > will fail (and on the next boot, the user's settings will probably fail to > load). It happened to me after my latop got stuck, and I forced a power down using the hardware power button. After the reboot, all my settings were lost, and can't be changed. I believe this is an SELinux / gvfs bug: Jun 18 20:14:11 Fedora19 kernel: [ 9.834251] type=1400 audit(1371611643.411:4): avc: denied { relabelfrom } for pid=281 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=13096 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 20:21:55 Fedora19 kernel: [ 16.658571] type=1400 audit(1371612107.319:4): avc: denied { relabelfrom } for pid=257 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=14133 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 20:36:30 Fedora19 systemd-tmpfiles[1993]: stat(/run/user/1000/gvfs) failed: Permission denied Jun 18 21:00:03 Fedora19 kernel: [ 27.164783] type=1400 audit(1371614396.756:4): avc: denied { relabelfrom } for pid=251 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=11761 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 21:14:29 Fedora19 systemd-tmpfiles[2509]: stat(/run/user/1001/gvfs) failed: Permission denied Jun 18 22:11:11 Fedora19 kernel: [ 284.019727] type=1400 audit(1371618668.763:4): avc: denied { relabelfrom } for pid=280 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=12797 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 22:21:24 Fedora19 systemd-tmpfiles[1426]: stat(/run/user/1001/gvfs) failed: Permission denied Jun 18 22:49:52 Fedora19 kernel: [ 10.533060] type=1400 audit(1371620988.504:4): avc: denied { relabelfrom } for pid=275 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=9028 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 23:04:38 Fedora19 systemd-tmpfiles[2112]: stat(/run/user/1000/gvfs) failed: Permission denied #============= systemd_tmpfiles_t ============== #!!!! This avc is allowed in the current policy allow systemd_tmpfiles_t iscsi_lock_t:file relabelfrom; commit da84df01a4f2967a9766e496b0396f7578a7741a Author: Miroslav Grepl <mgrepl> Date: Tue Jun 18 08:30:55 2013 +0200 Allow systemd-tmpfiles to relabel also lock files Please advise on gvfs. Is the selinux issue really all there is to this, or could there be more? Well, it could be more. What does # ls -lZ /run/user/1001/ # ls -lZ /run/user/1001/ ls: cannot access /run/user/1001/gvfs: Permission denied drwx------. dan2 dan2 unconfined_u:object_r:config_home_t:s0 dconf ?--------- ? ? gvfs drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 keyring-0Pd395 drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 keyring-4obl7j drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 pulse lrwxrwxrwx. root root system_u:object_r:user_tmp_t:s0 X11-display -> /tmp/.X11-unix/X0 Dan, does it work in permissive mode? Yes permissive mode helps out big time. Instead of the 10 x-caja-desktop I was getting on first login I get one now. [root@Fedora19 dan3]# cat /var/log/messages |grep denied Jun 18 20:14:11 Fedora19 kernel: [ 9.834251] type=1400 audit(1371611643.411:4): avc: denied { relabelfrom } for pid=281 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=13096 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 20:21:55 Fedora19 kernel: [ 16.658571] type=1400 audit(1371612107.319:4): avc: denied { relabelfrom } for pid=257 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=14133 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 20:36:30 Fedora19 systemd-tmpfiles[1993]: stat(/run/user/1000/gvfs) failed: Permission denied Jun 18 21:00:03 Fedora19 kernel: [ 27.164783] type=1400 audit(1371614396.756:4): avc: denied { relabelfrom } for pid=251 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=11761 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 21:14:29 Fedora19 systemd-tmpfiles[2509]: stat(/run/user/1001/gvfs) failed: Permission denied Jun 18 22:11:11 Fedora19 kernel: [ 284.019727] type=1400 audit(1371618668.763:4): avc: denied { relabelfrom } for pid=280 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=12797 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 22:21:24 Fedora19 systemd-tmpfiles[1426]: stat(/run/user/1001/gvfs) failed: Permission denied Jun 18 22:49:52 Fedora19 kernel: [ 10.533060] type=1400 audit(1371620988.504:4): avc: denied { relabelfrom } for pid=275 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=9028 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 18 23:04:38 Fedora19 systemd-tmpfiles[2112]: stat(/run/user/1000/gvfs) failed: Permission denied Jun 19 01:01:34 Fedora19 kernel: [ 6.529689] type=1400 audit(1371628888.856:3): avc: denied { relabelfrom } for pid=253 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=10621 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file Jun 19 01:01:34 Fedora19 kernel: [ 6.529689] type=1400 audit(1371628888.856:4): avc: denied { relabelto } for pid=253 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=10621 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file [root@Fedora19 dan3]# cat .xsession-errors touch: cannot touch ‘/home/dan3/.cache/imsettings/log’: No such file or directory ** (abrt:1660): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** (nm-applet:1676): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. vmware-user: could not open /proc/fs/vmblock/dev W: [pulseaudio] authkey.c: Failed to open cookie file '/home/dan3/.config/pulse/cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to load authorization key '/home/dan3/.config/pulse/cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to open cookie file '/home/dan3/.pulse-cookie': No such file or directory W: [pulseaudio] authkey.c: Failed to load authorization key '/home/dan3/.pulse-cookie': No such file or directory abrt-applet: Can't access '/var/tmp/abrt/ccpp-2013-06-18-22:23:06-1336': Permission denied ** (nm-applet:1676): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist ** (nm-applet:1676): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist ** (mate-power-manager:1662): WARNING **: levels is 0! ** (abrt:1660): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist ** (abrt:1660): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist ** (caja:1677): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files ** Message: applet now removed from the notification area ** Message: applet now embedded in the notification area Dan, could you re-test it with the latest builds http://kojipkgs.fedoraproject.org//packages/selinux-policy/3.12.1/53.fc19/noarch/selinux-policy-3.12.1-53.fc19.noarch.rpm http://kojipkgs.fedoraproject.org//packages/selinux-policy/3.12.1/53.fc19/noarch/selinux-policy-targeted-3.12.1-53.fc19.noarch.rpm Turned on enforcing and seems to be showing 0 denials now. Will do a clean install tomorrow and test with this policy. Thanks Miroslav!!!! Hi, I have this problem too. I can't change any settings in GNOME. Also the processes tracker-miner-fs and dconf-service take about 250-300% of processor time (on 4 cores). Also systemd-journal and dbus-daemon takes about 50%. I've updated lot of things yesterday, but this happens after second restart (after update I restarted immediately and no problem occure). gvfs was in updates. I'm +1 for blocker, because system with this bug is quite unusable. Do we have more bugs in this bug? Petr, is your problem SELinux issue? I talked to Petr before and he said permissive selinux hadn't helped. I'm a bit confused, could SELinux really cause dbus errors as in comment 7 and the upstream reports, like this? (mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: > GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header I tried to do a clean F19 TC5 DVD installation and haven't seen this issue, so it really looks like a dconf database corruption that happens just sometimes. Maybe we should have two separate bugs, one for selinux and one for dbus? Yeah, that's what I meant with c#12, I'm worried Dan hijacked the bug for a different problem. There are 2 bugs, yes. I thought that fixing the SElinux ones might help. And it seems that they did, but we should file a separate bug on dbus I guess. The OP's journalctl output does have a line: Jun 18 12:23:46 localhost.localdomain systemd-tmpfiles[2038]: stat(/run/user/1000/gvfs) failed: Permission denied But that's well *after* the first dconf error: Jun 18 12:10:15 localhost.localdomain /etc/gdm/Xsession[1174]: (gnome-settings-daemon:1354): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header That error appears to happen just one second after the user logs in: Jun 18 12:10:14 localhost.localdomain gdm-password][1162]: pam_unix(gdm-password:session): session opened for user matt by (unknown)(uid=0) Right after user login, a Bunch Of Stuff happens: Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: ** (gnome-settings-daemon:985): WARNING **: Name taken or bus went away - shutting down Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.Power: The connection is closed Jun 18 12:10:14 localhost.localdomain gdm-launch-environment][952]: pam_unix(gdm-launch-environment:session): session closed for user gdm Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.XRANDR: The connection is closed Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.Keyboard: The connection is closed Jun 18 12:10:14 localhost.localdomain polkitd[478]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.31, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. which seems odd. Overall we're fairly sure the selinux stuff was a hijack, so sending this back to dconf for now. We still want the selinux fix, obviously, but it's really not this bug; perhaps a new one should be opened. Dan: you should file a new bug for selinux-policy, as this one was filed against dconf in the first place and you hijacked it. Did who's been affected by the 'corrupted file' version of this bug *not* see it after an unclean shutdown/restart? In particular, Matus, was there an unclean shutdown/restart in your test that you didn't mention? Or was this really a straightforward 'install F19, run g-i-s, now dconf is broken'? Matus: if you still have the affected VM and you didn't 'fix' it, I suspect we'd very much like you to attach the ~/.config/dconf/user file. Discussed at 2013-06-19 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . We agreed to delay the decision on this until we're clearer on the causes here. So far the desktop team is at least confident that the dconf database seems to be getting overwritten with all zeroes on unclean shutdown fairly often, and is inclined to blame this on some kind of kernel change. There has been some discussion about whether dconf can mitigate this by backing the database up periodically and restoring the last backup if the 'active' file gets zapped. We are not sure if there is some further issue that can cause problems with the database even without any kind of unclean shutdown. Eric, can you comment if there have been any recent kernel changes which may explain why we're suddenly seeing the dconf database (which is just a file, ~/.config/dconf/user ) get overwritten with all zeroes on unclean shutdowns? Some discussion from #fedora-desktop: <desrt> mjg59: do you actually have a corrupted db? so far the only thing people have been able to provide me with are size-zero files and files filled with zeros <mjg59> Yeah, it's a (large) empty file <desrt> sigh <mjg59> Perhaps you have some more fine-grained definition of corrupt <desrt> what filesystem, and are you using any weird block-layer stuff (lvm, luks, etc)? <mjg59> ext4, no <desrt> so afaik, replace-by-rename is supposed to be a 'safe' operation on ext4, even across crashes/power-loss <mjg59> Ted probably broke it again But I'd gladly blame Ted for basically anything, so you shouldn't base any behaviour on my feelings here <desrt> ya.... the fact that we suddenly get all of these reports after no recent changes in dconf sort of points at changing kernel behaviour... <adamw> mjg59: yup, that's pretty much what happened to me OK, if I do a reset on my VM I can reproduce the dconf corruption: (mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header (mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header (mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header And yes .config/dconf/user is filled with junk. I did an install with the F19 TC5 live desktop x86_64 to a VM with two vdisks in RAID1. I had no problems changing dconf settings before forcing an unclean shutdown. After doing the unclean shutdown, I can't change my desktop and any changes I make to the overview's favourites are not persistent across reboot. .config/dconf/user is full of junk on this VM, all of a sudden, I keep getting crashes in tracker-miner which abrt is identifying as https://bugzilla.redhat.com/show_bug.cgi?id=975687 There are several log messages of the form: Jun 19 18:21:19 localhost /etc/gdm/Xsession[1165]: (tracker-miner-fs:1370): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header Yes, as mentioned above we're already pretty clear there's an issue with the file getting nerfed across unclean shutdowns. What's not quite certain at this point is whether there's a cause which doesn't involve an unclean shutdown. See: https://bugzilla.gnome.org/show_bug.cgi?id=701560 https://bugzilla.gnome.org/show_bug.cgi?id=637544 Fixed upstream, backported the patch, F19 candidate build started here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5525795 glib2-2.36.3-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19 Discussed at 2013-06-20 blocker: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-20/f19final-blocker-review-7.1.2013-06-20-15.01.html . Accepted as a blocker per criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs". This seems to be solidifying around 'it suddenly got much more likely that dconf database would get nerfed on an unclean shutdown'. Let's say this bug covers that. If we find some other cause, we'd better track that in another bug. Created attachment 763701 [details]
~/.config/dconf/user
~/.config/dconf/user contains only junk. Can those who are able to reproduce this easily please test with https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19 and confirm the fix? Thanks! Package glib2-2.36.3-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glib2-2.36.3-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11439/glib2-2.36.3-2.fc19 then log in and leave karma (feedback). OK, I verified this myself - did a TC5 live install, twiddled with a couple of dconf settings, forced a shut down of the VM, booted it up, and the problem was reproduced. Did the same thing with a live image I built with glib2-2.36.3-2 included, and it survived the hard shutdown/reboot OK. So setting VERIFIED. glib2-2.36.3-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 975523 has been marked as a duplicate of this bug. *** Just a note, even updating the glib2 package didn't fix it for me. I had to start with a fresh ~/.config/dconf/user database. Mine was full of null bytes: ~]$ od ~/.config/dconf/user 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 0077300 000000 0077302 Jeff, AFAIU, the new glib2 package should prevent this problem from happening, but doesn't fix the corrupted database if it already happened to you. You need to remove the file in this case, yes. I'm experiencing this bug on fully updated F19 right now. I did an unclean shutdown and the ~/.config/dconf/user database is corrupted. When I delete it and make changes using dconf-editor, even the database that appears right away is corrupted. So the changes only persist on the session they were made on. Logging out returns everything to default. I have glib2-2.36.3-3.fc19.x86_64. Sorry for the false alarm! I tried to test some other settings and they persist just fine. Also, I guess I tried to open the dconf database the wrong way and so I thought it is corrupt. Nevertheless, when I disable animations in org.gnome.desktop.interface.enable-animations - this does not persist. But it is probably not related to this bug. |