Symlink $XDG_RUNTIME_DIR/../dconf/user, and do not symlink $REALHOME/.

MarcusTomlinson commented 4 years ago

Bug report: https://bugs.launchpad.net/snapcraft/+bug/1661626 XDG link error: https://paste.ubuntu.com/p/5HHF5qwS2f/

kenvandine commented 4 years ago

I've tested this with the gnome-system-monitor snap, which exhibits this bug. This PR does fix the issue with gnome-system-monitor.

kenvandine commented 4 years ago

@jhenstridge can you please give this a review?

jhenstridge commented 4 years ago

This almost certainly looks wrong. From what I can tell, the $XDG_RUNTIME_DIR/dconf/user file is a two byte file used as a shared memory transport between dconf clients:

https://gitlab.gnome.org/GNOME/dconf/blob/master/shm/dconf-shm.c#L57

... while $XDG_CONFIG_HOME/dconf/user contains the user's settings:

https://gitlab.gnome.org/GNOME/dconf/blob/master/engine/dconf-engine-source-user.c#L46

Copying some other file into the location where the dconf backend expects to find the SHM file won't actually let it be used for IPC. I suspect that it appears to work anyway because the first byte of ~/.config/dconf/user is not a nul byte. This means dconf_shm_is_flagged will always return true, leading the backend to regularly reopen the settings file. We see new configuration values, but we're also doing a lot more IO than usual.

I think the correct option here would be to do something like:

if [ -r $XDG_RUNTIME_DIR/../dconf/user ]; then
  ensure_dir_exists $XDG_RUNTIME_DIR/dconf
  ln -sf ../dconf/user $XDG_RUNTIME_DIR/dconf/user
fi

I think this should all work with the permissions the gsettings interface grants.

MarcusTomlinson commented 4 years ago

Woot, thanks @jhenstridge! You're absolutely correct, thanks for demystifying this. Your suggestion worked like a charm, and makes far more sense too ;)

ubuntu / snapcraft-desktop-helpers

Symlink $XDG_RUNTIME_DIR/../dconf/user, and do not symlink $REALHOME/. #201