web-dev-qa-db-ja.com

ルートとしてgnome-terminalを起動しようとすると、「プロキシの構築中にエラーが発生しました...」

openSUSE Leap 42.2Gnomeターミナル3.20.2

ターミナルウィンドウを開いています。次のコマンドを入力すると：

gnome-terminal

root以外のユーザーとして、新しい端末を正常に起動します。

ただし、rootとしてコマンドを実行すると、次のエラーメッセージが表示されます。

Org.gnome.Terminal：/ org/gnome/Terminal/Factory0のプロキシの構築中にエラーが発生しました：接続が閉じられています

dbus-launch gnome-terminalでターミナルを起動しようとすると、動作します。

gnome-terminalコマンドがターミナルをrootとして起動するのを妨げているのは何ですか？そして、dbus-launchは許容できる回避策ですか、それとも予期しない問題を引き起こす可能性がありますか（私はそれが何をしているのか本当に理解していません）？

opensusegnome-terminald-bus
3
Owen Pauling

Windowsアプリケーションが主にWin32が登場する前のWin16日に機能し、それを廃止したことを思い出してください。hInstanceとhPrevInstanceがあり、多くのアプリケーションの2番目のインスタンスを実行しようとすると単純に手渡されました。最初のインスタンスに移行します。これにより、コマンドスクリプティングツール（Take Commandなど）では、アプリケーションを2回呼び出すと、追加ウィンドウとして画面に表示されますが、コマンドインタープリターまでは問題が発生します。実行したばかりの子プロセスがすぐに終了することを懸念していましたか？

GNOMEは、Linux用のWin16の動作を復活させました。

GNOMEターミナルはクライアントサーバーアプリケーションになりました。 gnome-terminalプログラムは、デスクトップバスメッセージをサーバーに構築し、コマンドラインオプション、環境、作業ディレクトリ、および引数を渡して、単に終了するクライアントです。サーバーはgnome-terminal-serverであり、デスクトップバス上でorg.gnome.Terminalとして登録され、実際の端末エミュレーションとGUIでのウィンドウの表示をすべて担当します。

gnome-terminalのようなデスクトップバスクライアントは、環境変数を介してデスクトップバスブローカーを見つけます。環境変数は通常、/run/user/1001のようなユーザーごとのディレクトリ内のソケットを指します。または、環境変数は「現在のユーザーのランタイムディレクトリ」を検索するように指定し、前述と同様のパスがクライアントプロセスの実効ユーザーIDから作成されます。いずれの場合も、このディレクトリは通常、個々のユーザーに対してプライベートであり、他の（特権のない）ユーザーにはアクセスできません。

人々がSudoなどを介して別のユーザーとしてgnome-terminalを実行しようとすると、陽気さが生じます。環境変数が明示的に名前が付けられたランタイムディレクトリを指している場合、特権のないクライアントはユーザーごとのデスクトップバスに接続できません。環境変数が「現在のユーザーの」ランタイムディレクトリを指している場合、間違ったデスクトップバスブローカーを探します。多くの場合、が現在持っていないユーザーのブローカーです。 -）ユーザーがログインしておらず、そのユーザーアカウントのユーザーごとのサービスを開始していないために実行されているDesktopBusブローカー。 （ユーザーごとのデスクトップバスブローカーは、ユーザーごとのサービスマネージャーによって実行されます。ユーザーごとのサービスマネージャーは、明示的に開始されるか、一部のサービス管理ソフトウェアの場合は、によって採用されているユーザー認証プロセスへのかなり醜いフックによって開始されます。 login、su、SSHサーバープログラムなど。）

dbus-launchがスーパーユーザーとして機能した理由は、dbus-launchがスーパーユーザーとして実行されている別のデスクトップバスブローカーを明示的に起動し、gnome-terminalが通信できたためです。幸い、システムは、クライアントがブローカーを介してサーバーに接続しようとしたときに、gnome-terminal-serverサーバーをデマンドスタートするようにも構成されていました。 （これは必ずしも当てはまるわけではなく、今日では、このようなデマンドスタートは、いかなる種類のサービス管理でも実行されていないデスクトップバスサーバープロセスが多数発生するため、劣ったメカニズムと見なされています。実際、ブローカー自体がありません。サービス管理下でも劣っていると見なされます。また、スーパーユーザーアカウントでこれらの種類のサービスを実行することも、一般的には良い考えではありません。スーパーユーザー特権で実行されることを期待しないでください。通常のユーザーアカウントの管理下で実行されることを期待しているからです。）

" ヘッドレスサーバーでgnome-terminalをリモートで起動するにはどうすればよいですか？（X11転送で起動できない） "の質問者がgnome-terminalを実行しようとすると、さらに陽気になります。元のユーザーでさえDesktopBusブローカーを実行していない場合。これは、たとえば、SSH経由でログインしたが、SSHログインプロセスがユーザーごとのサービスマネージャーを起動しない場合に発生します。つまり、ユーザーごとのデスクトップバスブローカーが実行されておらず、gnome-terminal-serverデスクトップバス経由でサーバーにアクセスできません。 （システムの構成方法によると、グラフィカルログインはユーザーごとのサービスマネージャーの起動をトリガーする可能性があるため、同じユーザーが魔法のように機能するようにグラフィカルにログインすると、dbus-launchが明示的に起動することがあります。サービス管理されていないデスクトップバスブローカー。）

login、su、およびSSHサーバーへのフックを持つサービスマネージャーの1つがある場合、さらに陽気になります。これらのフックは通常、ユーザーごとのサービス管理を開始するセマンティクスと、それが開始するすべてのユーザーごとのサービスを、そのユーザーの最初のログオン時に実装します。そして、そのユーザーの最後のログオフでそれらをすべて停止します。短期間の重複しないSSHセッションが多数ある場合、ユーザーごとのサービス管理システム全体（およびそのすべての自動起動サービス）を無用に起動およびシャットダウンすると、多くのオーバーヘッドが発生する可能性があります。これらの各SSHセッションの開始と終了。そのようなサービスマネージャーの1つであるsystemdには、これに対処するのは実際には半分しかない不完全な「長引く」メカニズムがあります。これは、ユーザーごとのサービス管理が最後のログオフ後に「長引く」ことを意味しますが、ユーザーごとのサービス管理の開始はまったく停止しません。

参考文献

9
JdeBP