Terminal et Nautilus ont cessé de fonctionner après un accident

9

Quelque chose s'est très mal passé et, après qu'un programme C ++ sur lequel je travaillais s'est écrasé, mon terminal et nautilus (fichiers) ont cessé de fonctionner.

J'ai réussi à installer Terminator (un autre émulateur de shell), voici ce que j'obtiens en essayant de démarrer Terminal à partir de Terminator:

(gnome-shell: 779): Clutter-CRITICAL **: 01: 49: 35.532: Impossible d'initialiser Clutter: Impossible d'initialiser le backend Clutter: aucun pilote disponible trouvé. (gnome-shell: 779): mutter-WARNING **: 01: 49: 35.532: Impossible d'initialiser Clutter.

Voici ce que j'obtiens lors du lancement de Nautilus (en quelque sorte je peux le lancer depuis Terminator mais pas en cliquant sur l'icône)

** (nautilus: 445): AVERTISSEMENT **: 01: 48: 33.021: AT-SPI: Impossible d'obtenir le chemin ou le nom du bureau ** (nautilus: 445): AVERTISSEMENT **: 01: 48: 33.026: AT-SPI : Impossible d'obtenir le chemin ou le nom du bureau ** (nautilus: 445): AVERTISSEMENT **: 01: 48: 33.031: AT-SPI: Impossible d'obtenir le chemin ou le nom du bureau

..... encore 10-15 répétitions de cette erreur ....

** (nautilus: 445): AVERTISSEMENT **: 01: 48: 33.509: AT-SPI: Impossible d'obtenir le chemin ou le nom du bureau ** (nautilus: 445): AVERTISSEMENT **: 01: 48: 33.509: AT-SPI : Impossible d'obtenir le chemin ou le nom du bureau

Y a-t-il des conseils sur la façon de ramener les choses à la normale?

EDIT: il persiste après le redémarrage.

nautilus gnome-terminal Rotkiv
la source
Peut-être une question stupide, mais cela persiste-t-il après un redémarrage? Mieux vaut ajouter cela à votre question.
vanadium
@vanadium Fair question! Il persiste après le redémarrage, j'ai fait le montage.
Rotkiv
1
Je viens de frapper cela aussi, et j'ai soumis un rapport de problème: bugs.chromium.org/p/chromium/issues/detail?id=988902
Daniel Fackrell

Réponses:

12

J'ai commencé à rencontrer les mêmes problèmes que vous décrivez aujourd'hui, apparemment sortis de nulle part. J'ai trouvé ma solution dans ce fil: https://forums.linuxmint.com/viewtopic.php?t=279168

(Pour la postérité) Installez d'abord Terminator ou Xterm pour obtenir un terminal fonctionnel. Ouvrez Synaptic Package Manager et installez-le à cet endroit.

Vérifiez les autorisations sur les fichiers de votre dossier de départ

find $HOME ! -user $USER

Soyez particulièrement à l'affût des fichiers .dbus

Vous pouvez résoudre toutes les autorisations à la fois avec

sudo chown -Rc $USER:$USER $HOME

De plus, j'ai supprimé les fichiers $HOME/.dbus/session-bus, supprimé Chrome Remote Desktop et ses données $HOME/.config/chrome-remote-desktopet redémarré. Mon hypothèse est que Chrome Remote Desktop s'est redémarré pendant une mise à jour et a écrit certains fichiers en tant que root dans le dossier d'accueil.

Michiel
la source
3
Je pense que ce pourrait être aussi chrome-remote-desktop dans mon cas. Vraiment bizarre. Quoi qu'il en soit. Ça fonctionne maintenant. Je vous remercie!
Rotkiv
Je suis content que cela ait aidé. Vous pouvez vérifier /var/log/apt/history.loget voir si chrome-remote-desktop apparaît en relation avec une mise à jour d'autre chose ces derniers jours.
Michiel
Cela m'est encore arrivé. Cette fois, il suffit de le supprimer à $HOME/.config/chrome-remote-desktopnouveau. Il y a donc certainement quelque chose.
Michiel
merci, cela m'a sauvé de la récupération.
Montenegrodr
Cette réponse m'aide aussi. J'ai mis à jour Ubuntu de la version 18.04 à 19.04 et j'avais installé l' chrome-remote-desktopapplication. Les étapes de la réponse et du redémarrage avaient résolu le problème.
voleger
2

Comme le mentionne la réponse ci-dessus, le répertoire ~ / .dbus / est important. S'il n'existe pas, créez-le.

Si cela ne vous aide pas non plus, définissez la variable d'environnement NO_AT_BRIDGE=1.

Alcaro
la source
2

Après avoir travaillé avec l'équipe de chromotage via https://bugs.chromium.org/p/chromium/issues/detail?id=988902 , voici ce que j'ai appris:

Gnome (et peut-être XFCE et d'autres) ne gère actuellement pas très gracieusement plusieurs sessions pour le même utilisateur.

Dans ce cas, l'ajout de Chrome Remote Desktop a provoqué la création d'une session Gnome par défaut pouvant être connectée à l'aide du client CRD. Étant donné que cette deuxième session a été créée initialement après la session locale, tout semble bien se passer sur la session locale et le problème peut passer complètement inaperçu jusqu'au prochain redémarrage.

Cependant, après un redémarrage, la session distante s'exécute au démarrage, récupérant les ressources qui seraient normalement utilisées pour la session locale. Cela peut inclure la prise dbus, le système audio, le trousseau de clés de l'utilisateur et peut-être d'autres que je n'ai pas trouvés.

Étant donné que ceux-ci ne sont plus disponibles pour la session locale qui démarre plus tard, toute application ou fonctionnalité qui nécessite leur utilisation échoue, et le fait apparemment en silence, sauf si vous savez où trouver les journaux pertinents.

La solution de contournement recommandée pour l'instant consiste à configurer CRD pour utiliser un type de session différent, par exemple en créant un fichier ~ / .chrome-remote-desktop-session avec la configuration souhaitée.

L'équipe de chromotage a un correctif qu'elle déploiera dans une version plus récente qui devrait améliorer considérablement l'expérience utilisateur.

Daniel Fackrell
la source