这是我的疑问的史前史,如果需要更多细节,实际问题在第二段。
因此,我在不同的 Linux 发行版上使用独立窗口管理器已经有几个月了,并且为了启动 WM,我只需将其放入exec awesome
.xinitrc 中,因此我没有启动 dbus 守护程序。在像 Debian 这样的 systemd 系统上,我注意到每当我运行 AwesomeWM 时,D-Bus 用户会话就会自动启动。当我使用带有 runit init 系统的 Void Linux 时也会发生同样的情况。现在,我在 Artix Linux 上将 Emacs 作为窗口管理器运行,它也不使用 systemd,在我的 .xinitrc 中使用此行exec emacs
,它运行得很好。但是 Emacs 没有启动 dbus 守护程序,因此在其中运行的所有应用程序都不使用 DBus。我怀疑这有问题。
如果使用没有 D-Bus 会话守护进程的独立窗口管理器,是否意味着我的应用程序的某些功能可能无法使用?或者,如果我的窗口管理器在没有 D-Bus 守护进程的情况下也能正常工作,是否意味着我使用的应用程序不使用 D-Bus?那么,如果某个应用程序需要 D-Bus 会话,会发生什么情况?或者,如果会话本地 D-Bus 守护进程不可用,我的应用程序可能会连接到系统范围的 D-Bus 守护进程?这怎么可能呢?
答案1
许多程序根本不使用 D-Bus,或者不使用会议总线(例如,它们可能只需要与系统总线上的服务通信),或者在会话总线不可用的情况下有后备方案。例如,邮件应用程序可能只需要会话总线发送弹出通知(由 awesomewm 的naughty
模块显示)而不需要其他任何操作,因此即使总线不可用,应用程序的 99% 的功能仍然保留。
(会话和系统总线不可互换 - 它们具有不同的目的和不同的策略。每个系统只有一个系统总线,但每个 UID(或传统上每个 X11 显示器)有一个会话总线;系统总线只允许特权进程“托管”服务,而会话总线将所有特权授予它正在运行的任何 UID。)
然而,libdbus(最常用的 D-Bus 客户端库)有一个自动启动机制,如果尚无可用,它将自动生成一个dbus-daemon --session
。只要您的发行版未禁用此功能,第一个需要会话总线的程序将导致自动启动一个,并将其套接字地址存储在其中,~/.dbus/
以供其他程序查找。
自动启动并不是很好,原因与“sudo /etc/init.d/foo start”一样——有时原本只影响一个特定应用程序的不需要的环境可能会泄漏到自动生成的守护进程中,并从中泄漏到所有总线生成的服务中。因此,在基于 systemd 的发行版中,“用户会话”总线作为用户服务启动(这发生在登录时,远在 WM 启动之前),而在其他发行版中,通常建议从 xinitrc 中明确启动它。
(随着越来越多的应用程序出于各种目的使用会话总线,我建议启动它,即使你的设置中没有任何内容需要会话总线然而。守护进程仅在实际转发消息时才使用资源,因此让它在后台空闲也不会有什么坏处。)
如果你的 xinitrc 中只启动一件事,最简单的方法是将其包装在dbus-run-session
:
exec dbus-run-session awesomewm
对于更复杂的 xinitrc 脚本,可以将全部的脚本:
if [ ! "$DBUS_SESSION_BUS_ADDRESS" ]; then
exec dbus-run-session -- "$0" "$@"
fi
xbindkeys &
exec emacs
或者使用以下方式启动总线dbus-launch
:
if [ ! "$DBUS_SESSION_BUS_ADDRESS" ]; then
eval "$(dbus-launch --sh-syntax --exit-with-x11)"
fi