「su」で「systemctl --user」を実行しないと、なぜ問題が発生しますか?

「su」で「systemctl --user」を実行しないと、なぜ問題が発生しますか?

最近Lubuntu 22.04インストールでsystemctl --userユーザー1000として実行すると、次のようになります。

❯ systemctl status --user
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
❯ eval $(dbus-launch --sh-syntax)
❯ systemctl status --user
Failed to read server status: Process org.freedesktop.systemd1 exited with status 1

ただし、他のユーザー(1001)または同じユーザーを使用すると、viaは正常にsu $user機能します。systemctl status --user

データ:

  • ユーザー1001がアクティブなttyセッションを持っている場合(suそのセッションがアクティブであることをls /run/user示し1001、表示します)。systemctl status user-1001.slice
  • journalctl -u user-1000.sliceエラーは表示されません。
  • 問題は、新しく作成されたユーザーにも同じです。
  • ユーザ1000は「デルタ」でありsu delta(デルタのsshセッションで)実行された後、systemclt --user全てがうまく動作する。何とかsu必要な環境が作成されますが、SSHは生成されません。

問題をデバッグするには何ができますか? systemd状態設定を新しい状態に復元できますか?それとも1002から1001までコピーしますか?

ベストアンサー1

次から借りる:

D-Bus接続を取得できません:接続が拒否されました。

が等しくないFailed to connect to busときに得られます。これは、あるユーザーとしてログインし、別のユーザーとしてログインした場合に発生する可能性があります。$XDG_RUNTIME_DIR$UIDsu

ユーザーとしてログインしたようです1000。それからsuそれを使うことができます1001。ユーザーとしてバスを使用しようとしていますsystemctl --userが、同じことをやり直すまで機能しません1001su 1000 ...$UID$XDG_RUNTIME_DIR

この状況に陥る他の方法があるかもしれません。

su解決策はそれをまったく使用しないことです。 ~によるとシステム開発者:

「su」は、ユーザーのアイデンティティと少数の他のプロセスの資格情報を一時的に変更するために使用されるツールです。まったく新しいログインセッションを開くツールではありません。新しいログインセッションには明確に定義された元の設定があり、他のセッションから何も継承しませんが、「su」uidの変更は実際には行いません。ほとんどの実行環境は、MAC コンテキストなど、実質的で明白ではない方法で継承されます。監査コンテキスト、cgroupコンテキスト、名前空間コンテキスト、予約、タイマー粒度、

代わりに、フルセッションでログインしていることを確認してください。これを行ういくつかの方法:

  • 新しいTTYを開いてログインします。
  • machinectl loginまたはmachinectl shell [email protected]
  • ssh [email protected]
  • ディスプレイマネージャを終了して再度ログインします。

おすすめ記事