Terminal e Nautilus hanno smesso di funzionare dopo un incidente

Qualcosa è andato terribilmente storto e, dopo un programma C ++ su cui stavo lavorando, il mio terminale e nautilus (file) hanno smesso di funzionare.

Sono riuscito a installare Terminator (un altro emulatore di shell), ecco cosa ottengo quando provo ad avviare Terminator da Terminator:

(gnome-shell: 779): Clutter-CRITICAL **: 01: 49: 35.532: Impossibile inizializzare il Clutter: impossibile inizializzare il back-end del Clutter: nessun driver disponibile trovato. (gnome-shell: 779): mutter-WARNING **: 01: 49: 35.532: impossibile inizializzare Clutter.

Ecco cosa ottengo quando lancio Nautilus (tra l'altro in qualche modo posso avviarlo da Terminator ma non facendo clic sull'icona)

** (nautilus: 445): AVVISO **: 01: 48: 33.021: AT-SPI: Impossibile ottenere il percorso o il nome del desktop ** (nautilus: 445): AVVISO **: 01: 48: 33.026: AT-SPI : Impossibile ottenere il percorso o il nome del desktop ** (nautilus: 445): ATTENZIONE **: 01: 48: 33.031: AT-SPI: Impossibile ottenere il percorso o il nome del desktop

..... altre 10-15 ripetizioni di quell'errore ....

** (nautilus: 445): ATTENZIONE **: 01: 48: 33.509: AT-SPI: Impossibile ottenere il percorso o il nome del desktop ** (nautilus: 445): ATTENZIONE **: 01: 48: 33.509: AT-SPI : Impossibile ottenere il percorso o il nome del desktop

Qualche suggerimento su come posso riportare le cose alla normalità?

EDIT: persiste dopo il riavvio.

Ho iniziato a sperimentare gli stessi problemi che descrivi oggi, apparentemente dal nulla. Ho trovato la mia soluzione in questo thread: https://forums.linuxmint.com/viewtopic.php?t=279168

(Per i posteri) Prima installa Terminator o Xterm per ottenere un terminale funzionante. Apri Synaptic Package Manager e installalo lì.

Controlla le autorizzazioni sui file nella cartella principale

find $HOME ! -user $USER

In particolare, cerca i file in .dbus

Puoi risolvere tutte le autorizzazioni contemporaneamente con

sudo chown -Rc $USER:$USER $HOME

Inoltre, ho rimosso i file $HOME/.dbus/session-bus, rimosso Chrome Remote Desktop e i suoi dati $HOME/.config/chrome-remote-desktope riavviato. La mia ipotesi è che Chrome Remote Desktop si è riavviato durante un aggiornamento e ha scritto alcuni file come root nella cartella principale.

Come menzionato nella risposta sopra, la directory ~ / .dbus / è importante. Se non esiste, crealo.

Se neanche questo aiuta, imposta la variabile d'ambiente NO_AT_BRIDGE=1.

Dopo aver lavorato con il team di chromoting tramite https://bugs.chromium.org/p/chromium/issues/detail?id=988902 , ecco cosa ho imparato:

Gnome (e forse XFCE e altri) al momento non gestisce più sessioni per lo stesso utente con molta grazia.

In questo caso, l'aggiunta di Chrome Remote Desktop ha causato la creazione di una sessione Gnome predefinita che potrebbe essere connessa tramite il client CRD. Poiché questa seconda sessione è stata creata dopo la sessione locale inizialmente, tutto sembra andare bene nella sessione locale e il problema potrebbe passare completamente inosservato fino al prossimo riavvio.

Dopo un riavvio, tuttavia, la sessione remota viene eseguita all'avvio, acquisendo risorse che normalmente verrebbero utilizzate per la sessione locale. Questo può includere il socket dbus, il sistema audio, il portachiavi dell'utente e forse altri che non ho trovato.

Poiché questi non sono più disponibili per la sessione locale avviata in un secondo momento, qualsiasi applicazione o funzionalità che richiede il loro utilizzo ha esito negativo e lo fa apparentemente in silenzio a meno che non si sappia dove trovare i registri pertinenti.

La soluzione alternativa consigliata per ora è configurare CRD in modo che utilizzi un tipo di sessione diverso, ad esempio creando un file ~ / .chrome-remote-desktop-session con la configurazione desiderata.

Il team di chromoting ha una patch che verrà implementata in una versione più recente che dovrebbe migliorare significativamente l'esperienza dell'utente.