Krdytkyu

I run Ubuntu 12.04.1 LTS x64 in VirtualBox. After one very unfortunate misclick (reset saved state instead of load saved state) I got a very annoying problem.

Almost all applications (unity, synaptic, gedit, etc.) print on start:

Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

And all GUI settings reset after reboot.

Another symptom:

$ GSETTINGS_BACKEND=dconf dconf-editor

(dconf-editor:2353): GLib-GIO-WARNING **: Can't find module 'dconf' specified in GSETTINGS_BACKEND

GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications

But /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so is present.

What I tried (and it didn't help):

• sudo apt-get install -f --reinstall dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service


• Build dconf-0.5 from sources and make install it


• Create empty user profile and start programs there

I have to keep current Ubuntu installation so a complete reinstall is not an option for me.

How can I fix it?

I've found the solution. It appears that I got several custom-built libraries in /usr/local/lib that "shadowed" system libraries from /usr/lib/x86_64-linux-gnu/.

I discovered it by checking dynamic libraries loaded by libdconfsettings.so:

ldd /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so



...

<  several dynamic libraries from /usr/local/lib >

...

It happened because of the order of search paths for dynamic libraries (defined in /etc/ld.so.conf.d/). The order was the following:

1. /lib/i386-linux-gnu


2. /usr/lib/i386-linux-gnu


3. /lib/i686-linux-gnu


4. /usr/lib/i686-linux-gnu


5. /usr/local/lib


6. /lib/x86_64-linux-gnu


7. /usr/lib/x86_64-linux-gnu

So if for example you put your own libc.so into /usr/local/lib it will be loaded instead of default libc.so from /lib/x86_64-linux-gnu.

The fix:

sudo mv /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/xuserlocal.conf

sudo ldconfig

sudo reboot

This can also happen if you have PATH conflicts with a Python enviroment manager like Anaconda.

Make sure to run which gsettings before getting too deep. If that doesn't print /usr/bin/gsettings and instead something like /home/{username}/anaconda3/bin/gsettings you probably have something .profile like:

export PATH=$HOME/anaconda3/bin:$PATH

Change it to:
export PATH=$PATH:$HOME/anaconda3/bin

Appending instead of preprending to the PATH variable will solve your issue, but be aware that anything in your system bin, or other PATH locations, will supersede your anaconda3/bin.

Another option would be to alias /usr/bin/gsettings:

alias sys-gsettings=/usr/bin/gsettings

sys-gsettings get org.gnome.todo view

First check if this command returns true:

gsettings writable com.canonical.Unity.Launcher favorites

If not, install the backend with:

sudo apt-get install dconf-gsettings-backend 

If this doesn't help either, reset your profile with:

rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*

Afterwards reboot.

Just wanted to add my personal experience on this with ubuntu 16.10. Mine stopped working after using GNOME desktop environment for a while, and then switching to Unity to show a friend how nasty it looked (IMO :D), and back to GNOME. I then started getting the "...using memory backend...".

Doing

rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*

sudo ldconfig

sudo reboot

Fixed it for me.

I experienced same thing in Debian Jessie.
But questioner's solution (he had failed with it) was proper for my case:

 sudo apt-get install -f --reinstall  dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service

This problem had been killing me, but you saved my life, Thanks :D