dconf-WARNING **: échec de validation des modifications dans dconf: la connexion est fermée

11

Chaque fois que j'ouvre un logiciel via le terminal, je reçois les erreurs suivantes et, finalement, le logiciel s'ouvre

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)

Quel peut être le problème possible?

dconf

— Pawan Chauhan
source

7

J'ai eu le même problème, dans mon cas, je courais à "sudo gedit"partir d'un compte d'utilisateur; par conséquent, quand il a essayé d'enregistrer les modifications de dconf, il s'est rendu compte que l'utilisateur n'était pas root, et a donc soulevé ces erreurs. Je l'ai résolu en exécutant gedit en tant que "root":

sudo -i

gedit &

où sudo -ise connectera à un compte utilisateur.

— XAVI
source

1

THX. cet indice a résolu mon problème. (j'ai donc dû su - myotherusersu myotheruser

— me

ompiz --replace &

— David Ljung Madison Stellar

4

Cela m'énerve depuis longtemps. Je l'ai finalement résolu en utilisant gksudo -l <command>, qui exécute la commande dans un shell de connexion - de manière similaire à la réponse de XAVI mais sans avoir besoin de taper la commande après sudo.

— yosoy
source

4

Vous voudrez peut-être vérifier si les dossiers suivants appartiennent à root:

~/.cache/dconf
~/.dbus

Si tel est le cas, essayez de les supprimer. Selon d'autres sources que j'ai trouvées, ils devraient appartenir à vous-même, mais si vous avez exécuté des programmes graphiques avec, sudoils pourraient avoir été créés par root à la place. Les supprimer est apparemment sûr, car ils sont automatiquement recréés si nécessaire, mais peut-être les sauvegarder en premier.

— sp00n
source

0

J'ai donc eu ce problème aussi. Je n'ai pas eu la patience de travailler sur les différentes solutions fastidieuses et / ou inefficaces que j'ai trouvées sur les interwebs. Ce qui suit a fonctionné pour moi:

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

Non, ce n'est pas élégant. Mais ça marche. Je n'ai pas rencontré d' emacs stderr de bonne foi depuis des années (si jamais), alors à quel point cela peut-il être mauvais? Et vous pouvez coller un «alias» dans votre fichier .bashrc.

— Alex Rudnicky
source

Le problème avec cela est qu'il ne résout pas le problème :) Dans mon cas, nautilus ne peut pas enregistrer les modifications de configuration (par exemple, changer une option pour afficher les fichiers cachés.) Faire ce que vous suggérez cache l'erreur, mais cela ne 't résoudre l'erreur.

— luis.espinal