2009-09-14 15 views
12

¿Cómo es que siempre meLinux gedit: Siempre tengo "GConf error: error al conectar con el servidor de configuración ..."

"GConf Error: No se pudo contactar con el servidor de configuración; algunas causas posibles son que usted necesita habilite la red TCP/IP para ORBit, o tiene bloqueos NFS obsoletos debido a un bloqueo del sistema. Consulte http://projects.gnome.org/gconf/ para obtener información. (Detalles - 1: Error al conectarse a la sesión: No recibió una respuesta. Las causas posibles incluyen: la aplicación remota no envió una respuesta, la política de seguridad del bus de mensajes bloqueó la respuesta, el tiempo de espera de respuesta expiró o la conexión de red se rompió.) "

cuando ¿Comenzar 'gedit' desde un shell desde mi cuenta de superusuario?

+0

(y sí, eso es normal, no recuerdo cuál es el culpable, pero es una de las variables de entorno que impide el contacto con el servidor de configuración, muy probablemente 'HOME'). –

+1

Creo que esto pertenece a Super User o Server Fault. –

+0

Lo siento chicos ... me pasaré a Super Usuario. – jldupont

Respuesta

6

La respuesta técnica es que gedit es un programa Gtk +/Gnome, y espera encontrar una sesión de gconf actual para su configuración. Pero al ejecutarlo como un usuario separado que no está conectado en el escritorio, no lo encuentra. Entonces escupe una advertencia, diciéndote. Sin embargo, la falla debería ser benigna, y el editor aún se ejecutará.

La verdadera respuesta es: no hagas eso. No desea ejecutar aplicaciones de GUI como algo más que el usuario que ha iniciado sesión, en general. Y usted nunca quiere ejecutar cualquier aplicación GUI como root, nunca.

+0

Más útil ... ¡gracias! – jldupont

+0

¿Cuál es su argumento para estas prescripciones? –

+3

bien, no he votado negativamente, pero tampoco votaré porque "nunca" es demasiado duro. Ejecuto el administrador de archivos como root cuando quiero copiar fácilmente un montón de cosas pequeñas (root) sin tener que 'cp' todas ellas una a una. –

5

He estado utilizando aplicaciones de GUI como usuario registrado y como usuario secundario durante más de 15 años en varias máquinas UNIX. Hay muchas buenas razones para hacerlo (shell remoto, prueba de archivos de configuración, ejecutar múltiples sesiones de programas que solo permiten una instancia por usuario, etc.).

Hay un bug en la plataforma de lanzamiento que explica cómo eliminar este mensaje estableciendo la siguiente variable de entorno.

export DBUS_SESSION_BUS_ADDRESS="" 
+6

no funcionan. mismo 'GConf Error: no se pudo contactar con el servidor de configuración; ...' – askovpen

+0

Esto no funcionó, el mismo error continuó. – lkamal

+0

No hizo nada por mí. –

1

Ajuste y exportación DBUS_SESSION_BUS_ADDRESS a "" arreglaron el problema para mí. Solo tuve que hacer esto una vez y el problema fue resuelto permanentemente. Sin embargo,, si tiene un problema con su configuración de umask, como yo lo hice, entonces las aplicaciones de la GUI que está tratando de ejecutar pueden no ser capaces de crear correctamente los directorios y archivos que necesitan para funcionar correctamente.

Sugiero crear (o crear) una nueva cuenta de usuario únicamente con fines de prueba. Luego puede ver si todavía tiene el problema cuando inicia sesión en la nueva cuenta de usuario.

5

Para algunos (RHEL, CentOS) puede que tenga que instalar el paquete dbus-x11 ...

sudo yum install dbus-x11 

detalles adicionales here.

+1

La instalación del paquete dbus-x11 en nuestro servidor RHEL 6.7 eliminó la mayoría de las advertencias para mí, dejando solo dos advertencias relacionadas con iconos de tema faltantes. – converter42

0

Me encontré con este problema yo mismo en varios servidores diferentes. Probé todas las sugerencias enumeradas aquí: me aseguré de que ~/.dbus tuviera la propiedad adecuada, el servicio de reinicio de messagbus, etc.

Me resulta que mi ~/.dbus era el modo 755 y el problema desapareció cuando cambié el modo a 700. Encontré esto al comparar servidores que funcionan conocidos con servidores que muestran este error.

+1

Recientemente me encontré con este problema de nuevo. Los permisos en ~/.dbus estaban bien. Esto es lo que resolvió el problema la segunda vez que surgió: 1) rm/var/lib/dbus/id-mensaje 2) sudo service messagebus restart 3) export $ (dbus-launch) – Jaraxal

Cuestiones relacionadas