dconf-WARNING **: nie udało się zatwierdzić zmian w dconf: połączenie zostało zamknięte


11

Ilekroć otwieram jakiekolwiek oprogramowanie przez Terminal, pojawiają się następujące błędy i ostatecznie oprogramowanie się otwiera

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)

Jaki może być możliwy problem?

Odpowiedzi:


7

Miałem ten sam problem, w moim przypadku działałem "sudo gedit"z konta użytkownika; dlatego, gdy próbował zapisać zmiany dconf, zdał sobie sprawę, że użytkownik nie był rootem, i w ten sposób podniósł te błędy. Rozwiązałem to, uruchamiając gedit jako „root”:

sudo -i

gedit &

gdzie sudo -izaloguje się do konta użytkownika.


1
dzięki. ta wskazówka rozwiązała mój problem. (więc musiałem zalogować się za pośrednictwem su - myotheruserzamiast su myotheruser.)
comonad

ompiz --replace &
David Ljung Madison Stellar

4

Od dawna działa mi to na nerwy. W końcu rozwiązałem to za pomocą gksudo -l <command>, która uruchamia polecenie w powłoce logowania - podobnie jak odpowiedź XAVI, ale bez konieczności wpisywania polecenia po sudo.


4

Możesz sprawdzić, czy następujące foldery są własnością root:

~/.cache/dconf
~/.dbus

Jeśli tak, spróbuj je usunąć. Według innych źródeł, które znalazłem, powinny one być własnością ciebie, ale jeśli uruchomiłeś programy graficzne z sudonimi, mogły zostać utworzone przez roota. Usunięcie ich jest najwyraźniej bezpieczne, ponieważ są one automatycznie odtwarzane w razie potrzeby, ale być może najpierw wykonaj kopię zapasową.


0

Miałem też ten problem. Nie miałem cierpliwości, aby pracować nad różnymi żmudnymi i / lub nieskutecznymi rozwiązaniami, które znalazłem w interwebach. Dla mnie działało:

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

Nie, to nie jest eleganckie. Ale to działa. Nie spotkałem żadnego bona fide emacsa stderra od lat (jeśli w ogóle), więc jak źle to może być? I możesz wstawić „alias” w pliku .bashrc.


Problem polega na tym, że nie rozwiązuje problemu :) W moim przypadku nautilus nie jest w stanie zapisać zmian konfiguracji (powiedzmy, zmieniając opcję wyświetlania ukrytych plików). Robienie tego, co sugerujesz, po prostu ukrywa błąd, ale nie nie rozwiązuje błędu.
luis.espinal
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.