Errore durante la creazione del proxy per
org.gnome.Terminal:/org/gnome/Terminal/Factory0:la connessione è
chiusa

Se provo ad avviare il terminale con dbus-launch gnome-terminal allora funziona.

Cosa impedisce il gnome-terminal comando per avviare il terminale come root? Ed è dbus-launch una soluzione alternativa accettabile o che potrebbe causare problemi imprevisti (non capisco davvero cosa stia facendo)?

Risposta accettata:

Ricorda come le applicazioni Windows funzionavano principalmente nei giorni Win16 prima che Win32 arrivasse e lo eliminasse:dove c'erano hInstance e hPrevInstance , il tentativo di eseguire una seconda istanza di molte applicazioni passava semplicemente le cose alla prima istanza, e questo rendeva le cose difficili per gli strumenti di scripting dei comandi (come Take Command) perché si invocava un'applicazione una seconda volta, sarebbe visibilmente presente sul schermo come finestra aggiunta, ma per quanto riguarda l'interprete dei comandi il processo figlio che aveva appena eseguito è uscito immediatamente?

Bene, GNOME ha riportato il comportamento di Win16 per Linux.

GNOME Terminal è ora un'applicazione client-server. Il gnome-terminal programma è solo un client che costruisce messaggi Desktop Bus a un server, passando lungo le opzioni della riga di comando, l'ambiente, la directory di lavoro e gli argomenti, quindi semplicemente esce. Il server è gnome-terminal-server che si registra come org.gnome.Terminal sul Desktop Bus e che è responsabile di tutta l'effettiva emulazione del terminale e della visualizzazione delle finestre sulle GUI.

Un client Desktop Bus come gnome-terminal individua il broker Desktop Bus tramite una variabile di ambiente, che di solito punta a socket in una directory per utente come /run/user/1001 . In alternativa, la variabile di ambiente specifica di cercare nella "directory di runtime dell'utente corrente" e un percorso simile al suddetto viene costruito dall'ID utente effettivo del processo client. Questa directory in entrambi i casi è convenzionalmente privata per il singolo utente e inaccessibile ad altri utenti (non privilegiati).

L'ilarità nasce quando le persone tentano di eseguire gnome-terminal come un altro utente tramite sudo e simili. Se la variabile di ambiente punta a una directory di runtime con nome esplicito, un client senza privilegi non può connettersi al bus desktop per utente. Se la variabile di ambiente punta alla directory di runtime "dell'utente corrente", cerca il broker Desktop Bus sbagliato, spesso quello di un utente che al momento non ha un broker Desktop Bus in esecuzione perché l'utente non ha effettuato l'accesso e ha avviato i servizi per utente di quell'account utente. (I broker Desktop Bus per utente sono gestiti da un gestore del servizio per utente. Il gestore del servizio per utente viene avviato in modo esplicito o, nel caso di alcuni software di gestione dei servizi, da alcuni hook piuttosto brutti nel processo di autenticazione dell'utente impiegato da simili a login , su e programmi server SSH.)

Il motivo per cui dbus-launch ha funzionato per te come superutente è che dbus-launch ha lanciato esplicitamente un altro broker Desktop Bus, in esecuzione come superutente, che gnome-terminal ha potuto parlare con. Fortunatamente, il sistema è stato configurato anche per avviare a richiesta il gnome-terminal-server server quando il client ha tentato di connettersi ad esso tramite il broker. (Questo non è necessariamente il caso, e al giorno d'oggi tale avvio della domanda è visto come un meccanismo inferiore in quanto finisce con molti processi del server Desktop Bus che non vengono eseguiti con alcun tipo di gestione del servizio. In effetti, non avere il broker stesso anche sotto la gestione del servizio è considerato inferiore. Inoltre, generalmente non è considerata una buona idea per il superutente account per avere questo tipo di servizi in esecuzione, poiché molti di loro non si aspettano di essere eseguiti con privilegi di superutente perché si aspettano di essere eseguiti sotto l'egida degli account utente ordinari.)

Ulteriore ilarità si verifica se, come l'interrogante in "Come posso avviare gnome-terminal in remoto sul mio server senza testa? (non si avvia tramite l'inoltro X11)", le persone tentano di eseguire gnome-terminal quando anche l'utente originale non ha un broker Desktop Bus in esecuzione. Ciò accade quando, ad esempio, si è effettuato l'accesso tramite SSH ma il processo di accesso SSH non avvia il gestore servizi per utente, il che a sua volta significa che il broker Desktop Bus per utente non è in esecuzione e il gnome-terminal-server non è possibile raggiungere il server tramite un bus desktop. (A seconda di come è configurato il sistema, l'accesso grafico potrebbe comunque attivare l'avvio del gestore del servizio per utente, e quindi si potrebbe osservare che l'accesso graficamente poiché lo stesso utente fa funzionare magicamente le cose. E ancora dbus-launch avvierà esplicitamente un broker Desktop Bus non gestito dal servizio.)

Ancora più ilarità ne consegue quando si ha uno dei gestori di servizi che ha gli hook in login , su e il server SSH. Questi hook di solito implementano la semantica dell'avvio della gestione del servizio per utente e tutti i servizi per utente che avvia, al primo accesso per quell'utente; e fermandoli tutti alla fine della disconnessione per quell'utente. Se si dispone di molte sessioni SSH di breve durata e non sovrapposte, è possibile che vengano generati molti costi generali avviando e arrestando inutilmente l'intero sistema di gestione dei servizi per utente (e tutti i suoi servizi di avvio automatico) a l'inizio e la fine di ciascuna di queste sessioni SSH. systemd, uno di questi gestori di servizi, ha un meccanismo imperfetto di "indugiare" che risolve questo problema solo a metà. Significa che la gestione del servizio per utente "rimane" dopo la disconnessione finale, ma non impedisce affatto l'avvio della gestione del servizio per utente.

Ulteriori letture

• Jonathan de Boyne Pollard (2016). /run/user/jim/dbus . “Gazzettatore”. Guida al gusto . Software. jdebp.eu.
• Jonathan de Boyne Pollard (2016). "servizi per utente". Guida al gusto . Software. jdebp.eu.
• Esegui vere istanze di processo multiple di gnome-terminal
• Rendi persistente il servizio di sistema dell'utente
• https://unix.stackexchange.com/a/323700/5132