It would be good if dconf worked reliably over NFS home directories without configuration changes.  Currently only the keyfile dconf backend works properly over nfs.

The gvdb backend could be changed to detect NFS and copy it's file to /run just as the keyfile backend currently does today.  This will have performance implications, so should only be done in the NFS case.

marga, are you looking into this? 

(slightly edited) IRC conversation:

<halfline> desrt: is it currently the case that users who use nfs mounted home directories need to manually configure dconf to have a working experience?
<halfline> (and that manual configuration is service-db:keyfile/user in /etc/dconf/profile/user ?
<desrt> halfline: correct.
<halfline> k, thanks
<desrt> halfline: not users per se, but their admin
<desrt> marga was working on a native-dconf-database backend for NFS in the same spirit as the keyfile backend
<desrt> but i didn't hear from her about it since she said she was starting
<halfline> desrt: out of curiosity what happens if an admin forgets to change the setting?
<desrt> but basically: it seems bad to switch from using the binary database to a keyfile automatically based on some magic numbers detected via statfs
<halfline> no change notifications between machines, or corrupted databases ?
<desrt> halfline: corrupted databases are almost impossible with dconf
<desrt> halfline: i'd say that the worst thing that will happen is pretty bad: random processes start getting SIGBUS
<desrt> as is a hazard of using mmap on nfs
<halfline> hmm
<halfline> yea that's pretty bad
<halfline> is there a way to query what backend dconf is using programatically?
<desrt> no.  not really.
<desrt> why do you feel that you need to?
<halfline> well i'd almost rather failwhale with a link to the sysadmin guide than have that happen
<desrt> halfline: check if ~ is NFS and check if DCONF_PROFILE is set or /etc/dconf/profile/user exists?
<halfline> although honestly i'd prefer switching from the binary to keyfile backend automatically based on magic numbers...
<desrt> well
<desrt> the 'proper' solution is to switch from the binary backend to the 'safe' binary backend
<desrt> and that's what marga was working on
<halfline> does a binary backend have any advantages over nfs ?
<desrt> no.  not really.
<desrt> except compatibility
<halfline> so why is that the proper solution then?
<desrt> the SIGBUS is fairly rare unless someone is actively making changes from a 3rd machine
<desrt> so people have been getting along with the current situation
<halfline> well, rare bugs are sometimes the worst
<desrt> if we introduced automatically switching to a new backend based on NFS those people would probably wonder why their settings suddenly disappeared
<halfline> i can just imagine 4 years from now some rhel customer complaining about apps crashing and then having hours of debugging fun
<desrt> halfline: ping marga about the backend when next she is online
<halfline> ah
<desrt> if she isn't going to do it, probably someone else should
<halfline> so one advantage of the binary backend is the settings will stick around
<desrt> it's not a difficult task
<desrt> the keyfile backend works like so:
<desrt> on every change (and on startup, if you imagine startup being an empty change) the following occurs:
<desrt> step 1: acquire lock
<desrt> step 2: read in database and emit any changes that may have occured, locally
<desrt> step 3: apply change, emitting signals for that too
<desrt> step 4: unlock
<desrt> 2/3 are done using normal posix IO
<desrt> and are basically copying the entire file
<desrt> so there is no advantage performance-wise to using a gvdb here
<desrt> which is why keyfile...
<desrt> you would just have to replace the step 2/3 with reading/writing a gvdb instead of keyfile
<desrt> which would not be difficult
<desrt> the key thing to understand is that for the keyfile backend, dconf stores a local copy in the xdg runtime dir
<desrt> and that's the one that gets mmaped by everyone
<desrt> you're only ever syncing up to the keyfile contents
<desrt> you'd do the same for the new backend, except just with a gvdb
<halfline> but with default backend, the dconf database isn't copied into /run
<halfline> everyone just mmaps from ~/.config ?
<desrt> correct