解決策 1:
dbus-launch(1) ごと:
<ブロック引用>D-Bus を使用しようとするプロセスに DBUS_SESSION_BUS_ADDRESS が設定されていない場合、デフォルトでは、プロセスは --autolaunch オプションを指定して dbus-launch を呼び出し、新しいセッション バスを起動するか、X ディスプレイで既存のバス アドレスを見つけようとします。または ~/.dbus/session-bus/ 内のファイル
自動起動が発生するたびに、新しいバスを開始する必要があったアプリケーションは、独自の小さな世界になります。多くのバス サービスを使用しようとすると、事実上まったく新しいセッションが開始される可能性があります。これは、アプリとアプリが何をしようとしているのかによって、最適ではないか、完全に壊れている可能性さえあります。
自動起動には 2 つの一般的な理由があります。 1 つはリモート マシンへの ssh です。
したがって、プログラムがそれを見つけることができるように、dbus-daemonを先制的に開始することが秘訣のようです。私が使用するもの:
<ブロック引用>
[[email protected] ~]$ dbus-launch --exit-with-session gnome-terminal
これは、gnome-terminal とは別に、dbus-daemon を起動し、$DBUS_SESSION_BUS_ADDRESS を gnome-terminal 内で 設定します .
gnome-terminal から実行されるすべての X プログラムは適切に動作し、gnome-terminal が終了すると dbus-launch がクリーンアップされます。
解決策 2:
dbus セッションが不明または存在しないため、問題が発生しないのではないかと思います。
実際、SSH セッションが開いている場合、dbus セッションは開始されません。一部のプログラムはそれを起動する可能性がありますが、セッションはそれを認識していません (したがって、閉じることができません)。
dbus セッションについて知らないということは、dbus を使用しているがそれ自体を起動しないプログラムが問題を抱えていることも意味します。
dbus セクションは、マシンごとおよび X11 ディスプレイごとにあります。それらの情報は $HOME/.dbus/session-bus/ に保存されますが、そこで参照されているプロセスは閉じられている可能性があるため、dbus の起動が必要かどうかを判断するには、追加のチェックが必要です。そうではなく、そこにある変数をセッションにエクスポートする必要があります。
その後、それは魅力のように機能します:)
以下を .bash_profile ファイルに入れました:
# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
dbus_session_file="$HOME/.dbus/session-bus/${machine_id}-${x_display}"
if [ -r "$dbus_session_file" ]; then
export $(grep '^DBUS.*=' "$dbus_session_file")
# check if PID still running, if not launch dbus
ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
[ "$?" != "0" ] && export $(dbus-launch) >& /dev/null
else
export $(dbus-launch) >& /dev/null
fi
fi
注:hostnamectl は systemd の一部であり、マシン ID を取得できます。dbus-launch は、必要な変数を表示します。 export $(dbus-launch)
を使用して dbus-launch の出力を取得し、変数をエクスポートします
非インタラクティブなセッションで実行したい場合 (ssh からコマンドを実行する場合など)、代わりに .bashrc に入れてみてください (ただし、bashrc はすべての開いているシェルで実行されることに注意してください)
解決策 3:
リモート X コマンドを実行しようとしたときに同じ問題が発生し、X ツールが終了した後にセッションを終了させました。
だから私は走りたかった
ssh -X [email protected] "firefox -no-remote"
しかし、使用する必要がありました:
ssh -X [email protected] 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'
Firefox を閉じると、ssh セッションも閉じられます。
更新 :
これにより、サーバー上で実行されている dbus-daemon プロセスの負荷が残っているように見えるため、これは最適ではありません。両方のアカウントに --exit-with-session を追加しても、元の動作に戻るため、役に立ちません
アップデート 2 :これは、(@lobo で提案されているように)一重引用符を使用し、kill -TERM $DBUS_SESSION_BUS_PID
を追加すると機能します Holgr Joukl が https://blog.dhampir.no/content/how-to-prevent-ssh-x-from-hanging-on-exit-when-dbus-is から提案したように、残りの dbus-daemon プロセスを強制終了します。 -中古)