DBus示例问题：on_name_acquired后立即触发on_name_lost（系统总线场景）

你遇到的这个问题确实和System DBus的权限管控机制直接相关——Session DBus对本地用户进程几乎没有限制，但System DBus有严格的安全策略，用来防止未授权进程占用系统级服务名称。当你把示例代码里的G_BUS_TYPE_SESSION换成G_BUS_TYPE_SYSTEM后，就触发了这个权限检查逻辑。

为什么会出现on_name_acquired后立刻触发on_name_lost？ #

System DBus的守护进程会先短暂允许你的进程获取服务名称（所以on_name_acquired回调会被调用），但紧接着会根据预设的安全策略检查你是否拥有持有该名称的权限。如果权限不足，DBus会立即收回这个名称，触发on_name_lost回调。这种“先授予再收回”的行为是System DBus的标准安全机制。

解决步骤：配置DBus权限策略 #

要让你的服务能稳定注册System总线的服务名称，需要添加对应的权限规则：

1. 创建System DBus策略文件 #

在/etc/dbus-1/system.d/目录下新建一个配置文件（文件名建议和你的服务名称对应），比如org.gtk.GDBus.Example.conf，内容如下：

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <!-- 替换成你的用户名，允许该用户持有目标服务名称 -->
  <policy user="your_username">
    <allow own="org.gtk.GDBus.Example"/>
    <allow send_destination="org.gtk.GDBus.Example"/>
    <allow receive_sender="org.gtk.GDBus.Example"/>
  </policy>
  <!-- 可选：允许所有用户与该服务通信 -->
  <!--
  <policy context="default">
    <allow send_destination="org.gtk.GDBus.Example"/>
    <allow receive_sender="org.gtk.GDBus.Example"/>
  </policy>
  -->
</busconfig>

注意替换两个关键内容：

• your_username：运行服务的本地用户名
• org.gtk.GDBus.Example：你代码里注册的服务名称（和示例代码里的一致即可）

2. 重启DBus服务让配置生效 #

保存文件后，执行以下命令重启System DBus守护进程：

sudo systemctl restart dbus

额外排查建议 #

• 查看DBus日志确认问题：通过journalctl -u dbus命令可以查看System DBus的详细日志，里面会明确记录权限拒绝的原因，帮你定位问题
• 遵守服务名称规范：DBus要求服务名称必须是反向域名格式（比如com.yourcompany.YourService），不要使用不符合规范的名称
• 避免占用系统预留名称：不要尝试注册org.freedesktop开头的服务名称，这类名称属于系统级服务，需要特殊权限或官方策略授权

内容的提问来源于stack exchange，提问作者Peter Soltys