dconf-WARNING **: error al confirmar los cambios en dconf: la conexión está cerrada

Cada vez que abro un software a través de la Terminal obtengo los siguientes errores y eventualmente se abre

dconf-WARNING **: failed to commit changes to dconf: The connection is closed

(gedit:3609): dconf-WARNING **: failed to commit changes to dconf: The connection is closed

(gedit:3609): dconf-WARNING **: failed to commit changes to dconf: The connection is closed
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)

¿Cuál puede ser el posible problema?

Tuve el mismo problema, en mi caso estaba corriendo "sudo gedit"desde una cuenta de usuario; por lo tanto, cuando intentó guardar los cambios de dconf, se dio cuenta de que el usuario no era root y, por lo tanto, provocó esos errores. Lo resolví ejecutando gedit como una "raíz":

sudo -i

gedit &

donde sudo -iiniciará sesión en una cuenta de usuario.

Esto me ha puesto de los nervios por mucho tiempo. Finalmente lo resolví usando gksudo -l <command>, que ejecuta el comando en un shell de inicio de sesión, de manera similar a la respuesta de XAVI pero sin la necesidad de escribir el comando después sudo.

Es posible que desee verificar si las siguientes carpetas son propiedad de root:

~/.cache/dconf
~/.dbus

Si es así, intente eliminarlos. Según otras fuentes que encontré, deberían ser de su propiedad, pero si ha ejecutado programas gráficos con sudoellos, podrían haber sido creados por root. Aparentemente, eliminarlos es seguro, ya que se recrean automáticamente según sea necesario, pero tal vez los respalde primero.

Entonces también tuve este problema. No tuve la paciencia para trabajar a través de las diversas soluciones tediosas y / o ineficaces que encontré en las redes. Lo siguiente funcionó para mí:

$ emacs foo.py 2>/dev/null &   # (assuming you have an Xserver running)

No, no es elegante. Pero funciona. No me he encontrado con ningún emacs stderr de buena fe durante años (si es que lo ha hecho), ¿qué tan malo puede ser? Y puede pegar un 'alias' en su archivo .bashrc.