1. 为什么你敲下systemctl start nginx却被告知“系统未以 systemd 启动”——从 init 系统本质讲清 systemctl 的运行前提你刚在一台新装的 Ubuntu 22.04 服务器上配好 Nginx信心满满地输入sudo systemctl start nginx终端却冷不丁甩出一行红字Failed to connect to bus: No such file or directory或者更直白的警告System has not been booted with systemd as init system (PID 1). Cant operate.这不是你的命令写错了也不是服务文件损坏了——这是你在用一把瑞士军刀去拧一颗根本不存在的螺丝。systemctl不是万能遥控器它只在一种特定操作系统架构下才真正“活着”必须由 systemd 作为 PID 1 的 init 进程启动的 Linux 系统。换句话说systemctl是 systemd 的“官方客户端”不是独立程序它背后依赖一个持续运行的、名为systemd的守护进程通常位于/usr/lib/systemd/systemd而这个进程必须是系统启动后第一个被内核加载并执行的用户空间程序即 init 进程。一旦系统启动时用的是sysvinit、upstart或容器环境里精简的tinisystemctl就会彻底失联——它连“总控室”的门都找不到。这解释了为什么你在 WSL1、某些轻量级 Docker 镜像如alpine:latest、或手动指定init/bin/bash启动的救援模式中永远无法让systemctl正常工作。它不是“坏了”而是“没上岗”。我第一次遇到这个问题是在调试一个基于 Debian 9 的嵌入式镜像时反复检查nginx.service文件语法、权限、路径折腾三小时才发现该镜像编译时压根没启用 systemd 支持init 进程是sysvinit。后来我养成了一个铁律任何涉及 systemctl 的操作前先执行ps -p 1 -o comm。如果输出是systemd恭喜你可以继续如果是init、bash、tini或其他立刻停手——后面所有start/enable/status命令都是对空气发号施令。这也直接关联到热搜词里高频出现的chkconfig 和 systemctl对比。chkconfig是 sysvinit 时代的遗老它管理的是/etc/init.d/下的 shell 脚本靠软链接控制不同 runlevel 的启动顺序而systemctl管理的是/usr/lib/systemd/system/和/etc/systemd/system/下的.service单元文件靠依赖声明After、Wants和状态机驱动。二者不是升级关系而是两套完全不同的操作系统启动哲学。强行在非 systemd 系统上安装systemd并期望systemctl工作就像给自行车加装喷气引擎——硬件不兼容接口不匹配只会引发更复杂的崩溃。真正的迁移路径只有一条重装一个以 systemd 为默认 init 的发行版如 Ubuntu 16.04、CentOS 7、Debian 8而非修补旧系统。提示ps -p 1 -o comm是诊断 init 系统的黄金命令比查/proc/1/cmdline更简洁可靠。在 CI/CD 流水线或自动化脚本中应将其作为systemctl操作的前置健康检查避免因环境误判导致部署失败。2.systemctl edit不是 vi 的替代品——理解编辑器链式调用与单元文件覆盖机制当你执行sudo systemctl edit nginx终端突然弹出一个空白的 vi 界面你本能地开始敲i进入插入模式写完[Service]段落后按Esc:wq退出……结果发现systemctl status nginx显示的配置毫无变化。你怀疑自己没保存又试一次还是无效。问题不在编辑器而在你没理解systemctl edit的底层逻辑它不是直接修改原始服务文件而是创建一个“覆盖层”drop-in目录并在其中生成一个优先级更高的片段文件。具体来说systemctl edit nginx实际执行的是以下原子操作链创建目录/etc/systemd/system/nginx.service.d/注意末尾的.d在该目录下生成一个时间戳命名的文件如override.conf启动$EDITOR默认是vi但可通过export EDITORnano临时切换编辑此文件保存退出后自动执行systemctl daemon-reload重新加载单元定义。关键点在于这个override.conf文件只允许包含[Service]、[Install]或[Unit]等段落且仅能覆盖原始nginx.service文件中已存在的键值对。例如若原始文件有Restarton-failure你可以在override.conf中写Restartalways来覆盖它但如果你写CustomKeyvaluesystemd 会静默忽略——它不支持新增任意字段。这种设计是刻意为之的安全机制防止用户意外破坏服务的核心依赖关系如Afternetwork.target或启动条件。我踩过最深的坑是在调试一个 Java 应用服务时想通过systemctl edit myapp增加 JVM 内存参数。我错误地在override.conf中写了[Service] EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 ExecStart/usr/bin/java -Xms512m -Xmx2g -jar /opt/myapp.jar结果服务启动失败日志显示ExecStart被重复定义。原因在于原始myapp.service文件中已经存在ExecStart行而override.conf中的ExecStart会完全替换它但原始文件可能还定义了WorkingDirectory或User等关键项这些在覆盖后全部丢失。正确做法是只覆盖需要变更的部分[Service] EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 # 不要重写 ExecStart只追加 JVM 参数 ExecStart ExecStart/usr/bin/java -Xms512m -Xmx2g -Dspring.profiles.activeprod -jar /opt/myapp.jar注意第二行ExecStart是清空指令第三行才是新定义——这是 systemd 的特殊语法用于重置继承的值。此外编辑器选择也暗藏玄机。systemctl edit默认调用$EDITOR环境变量指定的编辑器但若未设置则回退到$VISUAL最后才是vi。在无图形界面的服务器上nano对新手更友好。你可以在~/.bashrc中永久设置export EDITORnano export VISUALnano这样sudo systemctl edit也会生效因为sudo默认保留部分用户环境变量。但要注意sudo可能重置EDITOR最稳妥的方式是sudo EDITORnano systemctl edit nginx。注意systemctl edit创建的覆盖文件位于/etc/systemd/system/unit.service.d/其优先级高于/usr/lib/systemd/system/unit.service系统自带和/run/systemd/system/unit.service运行时生成但低于/etc/systemd/system/unit.service完整重写文件。若需彻底替换服务定义应直接编辑/etc/systemd/system/nginx.service并执行daemon-reload。3.WorkingDirectory不是 pwd 的快捷方式——解析 systemd 的进程上下文隔离模型在编写自定义服务时你可能习惯性地在[Service]段落里加上WorkingDirectory/opt/myapp以为这等同于在终端中执行cd /opt/myapp ./start.sh。但当服务启动后ps aux | grep myapp显示的进程工作目录却是/甚至日志里报错Cannot open config.json: No such file or directory。问题根源在于WorkingDirectory设置的不是“启动时的当前目录”而是“进程实际执行时的根上下文”它受 systemd 的安全沙箱机制严格约束。systemd 对每个服务进程施加了多层隔离文件系统命名空间File System Namespace默认启用PrivateTmpyes创建私有/tmpProtectHomeyes屏蔽/home、/root、/run/userProtectSystemfull挂载/usr、/boot、/etc为只读。这意味着即使你设了WorkingDirectory/opt/myapp如果/opt/myapp下的某个配置文件被ProtectSystem标记为只读进程依然无法写入。执行上下文Execution ContextWorkingDirectory必须指向一个进程有读取和执行权限的目录。若服务以Userwww-data运行而/opt/myapp所属用户是root且权限为750则www-data用户无法进入该目录WorkingDirectory设置直接失效进程回退到/。我曾在一个 Django 项目中栽跟头服务文件设置了WorkingDirectory/var/www/myproject但chown -R www-data:www-data /var/www/myproject后仍报错。排查发现ls -ld /var/www/myproject显示权限是drwxr-x---而www-data组确实有x执行权限但cd操作还需要r读权限来列出目录内容。WorkingDirectory的验证逻辑比cd更严格——它要求进程对该目录有r-x完整权限。最终解决方案是chmod 755 /var/www/myproject而非盲目放宽整个父目录。更隐蔽的问题是路径解析。WorkingDirectory接受绝对路径但不支持波浪号~或环境变量展开。写WorkingDirectory~myuser/app或WorkingDirectory$HOME/app会被 systemd 当作字面字符串处理导致目录不存在。必须使用绝对路径/home/myuser/app。此外若路径中包含空格或特殊字符如My App必须用双引号包裹WorkingDirectory/opt/My App否则 systemd 解析器会截断。另一个常被忽视的细节是WorkingDirectory与ExecStart的协同。假设你写[Service] WorkingDirectory/opt/myapp ExecStart/usr/bin/python3 app.pysystemd 会先chdir到/opt/myapp再执行python3 app.py。此时app.py的路径是相对于/opt/myapp的所以它必须真实存在于/opt/myapp/app.py。但如果你的app.py在/opt/myapp/src/app.py正确的写法是[Service] WorkingDirectory/opt/myapp ExecStart/usr/bin/python3 src/app.py而不是在ExecStart中写绝对路径/opt/myapp/src/app.py——这会让WorkingDirectory失去意义且违反了 systemd “明确声明上下文”的设计哲学。提示调试WorkingDirectory问题的最快方法是添加ExecStartPre/bin/sh -c pwd; ls -la它会在主进程启动前打印当前工作目录和内容直观验证路径是否可达、权限是否足够。4. 服务状态的“假死”陷阱active (exited)与inactive (dead)的本质区别执行systemctl status nginx时你可能见过两种看似相似却天差地别的状态Active: active (exited)Active: inactive (dead)直觉上“exited” 意味着进程已退出应该和 “dead” 一样是停止状态。但systemctl start nginx却能成功启动前者却对后者报错Failed to start nginx.service: Unit nginx.service is masked.。这并非 bug而是 systemd 对服务类型Type的精确建模所致。systemd 将服务分为六种类型其中最易混淆的是Typesimple默认ExecStart启动的进程即为主进程systemd 监控其生命周期。进程退出即状态变为inactive (dead)。TypeoneshotExecStart启动的进程退出后服务状态变为active (exited)表示“一次性任务已成功完成”。后续start命令会再次执行该命令。Nginx 默认是Typesimple但很多初学者会错误地将nginx -t配置测试写成服务[Unit] DescriptionNginx Config Test [Service] Typeoneshot ExecStart/usr/sbin/nginx -t执行systemctl start nginx-config-test后status显示active (exited)—— 这是完全正确的因为nginx -t本就是个快速执行并退出的命令。但若你误以为这是“服务正在运行”就大错特错。active (exited)在oneshot类型下代表“任务已完成”不代表进程在后台存活。更危险的是Typeforking。传统 SysV 服务如老版本 Apache启动时会 fork 出子进程后让父进程退出systemd 需要PIDFile指向子进程 PID 文件才能跟踪。若PIDFile路径错误或文件未生成systemctl status可能显示active (running)但实际进程早已崩溃——因为 systemd 只是“相信” PID 文件存在而未实时校验进程是否真在运行。我在线上环境遭遇过一次严重事故一个Typeforking的 Redis 服务PIDFile/var/run/redis.pid但启动脚本因权限问题未能成功写入该文件。systemctl status redis一直显示active (running)监控告警也沉默。直到业务请求超时登录服务器才发现ps aux | grep redis为空。根因是 systemd 的PIDFile机制存在单点信任缺陷它不主动kill -0 pid验证进程存活只依赖文件存在性。破解这类“假死”状态的唯一可靠方法是结合多维度验证systemctl is-active unit返回active或inactive脚本判断用systemctl is-failed unit返回failed表示服务崩溃systemctl show --propertySubState unit返回更细粒度状态如running、exited、dead最终极手段pgrep -f process_name或ss -tlnp | grep port直接检查进程和端口。对于关键服务我强制要求在ExecStartPost中添加健康检查[Service] ExecStartPost/bin/sh -c sleep 1; curl -f http://localhost:8080/health || exit 1确保服务不仅启动成功而且真正就绪。注意mask操作systemctl mask nginx会创建指向/dev/null的符号链接/etc/systemd/system/nginx.service彻底禁用该服务。unmask才能恢复。inactive (dead)状态本身不表示被 mask但mask后的状态必为inactive (dead)且start失败。5. 单元文件的“隐形依赖链”从Wants到BindsTo的权力梯度解析当你运行systemctl start myapp它顺利启动但某天你执行systemctl stop postgresqlmyapp却也跟着退出了。你翻遍myapp.service文件只找到Afterpostgresql.service没看到任何Stop相关指令。问题出在postgresql.service文件中的一行BindsTomyapp.service——这是 systemd 依赖关系中最具“支配力”的指令也是最容易被忽略的隐性控制开关。systemd 的依赖声明不是平等的而是一个严格的权力梯度依赖指令权力强度行为描述典型场景Wants★☆☆☆☆弱依赖。目标单元启动失败本单元仍可启动。Wantsnetwork.target希望网络就绪但无网络也能启动。Requires★★☆☆☆强依赖。目标单元启动失败本单元必然失败。Requiresredis.service应用必须有 Redis 才能启动。BindsTo★★★★☆绑定依赖。目标单元停止或失败本单元立即停止目标单元重启本单元也重启。BindsTodatabase.service数据库宕机应用必须立即下线。Conflicts★★★★★冲突依赖。目标单元启动本单元强制停止目标单元停止本单元可启动。Conflictsapache2.serviceNginx 和 Apache 不能共存。BindsTo的“绑定”特性意味着双向强耦合。postgresql.service中写BindsTomyapp.service等价于宣告“我的生存状态完全由 myapp 决定”。当管理员执行systemctl stop postgresqlsystemd 不仅停止 PostgreSQL还会顺手执行systemctl stop myapp—— 因为myapp的存在是postgresql运行的前提而postgresql的停止意味着前提已不成立。我曾在微服务架构中滥用BindsTo导致雪崩一个网关服务gateway.service用BindsToauth-service.service而auth-service又BindsToredis.service。当 Redis 因内存不足 OOM 被系统杀死redis.service状态变为failed→ 触发auth-service停止 → 进而触发gateway停止。整个 API 网关瞬间不可用而日志里只有零星的redis.service: Main process exited, codekilled, status9/KILL根本看不出级联效应。事后复盘auth-service对 Redis 应该是Requires启动时必须存在而非BindsTo运行时必须绑定网关对认证服务应是Wants希望可用但可降级。另一个陷阱是循环依赖。若A.service有WantsB.service而B.service有WantsA.servicesystemd 会拒绝启动两者报错Found ordering cycle。但若A用WantsBB用BindsToA则形成单向强依赖systemd 允许启动但A停止会导致B停止而B停止不会影响A—— 这种不对称性极易在复杂系统中埋下隐患。诊断依赖链的终极命令是systemctl list-dependencies --reverse --all myapp.service--reverse显示“谁依赖我”--all展开所有层级。它会清晰列出myapp.service ● └─postgresql.service ● └─network.target ● └─system.slice这比肉眼搜索Wants字段高效百倍。对于生产环境我建议将此命令加入部署后的健康检查脚本确保依赖关系符合设计预期。提示BindsTo不应滥用。它适用于“共生关系”极强的组件如数据库连接池与数据库实例。对于松耦合服务如 Web 前端与后端 API应使用AfterWants组合保持弹性。6.systemctl daemon-reload的“脏数据”风险何时 reload 会静默失败你修改了/etc/systemd/system/myapp.service满怀期待地执行sudo systemctl daemon-reload终端只返回空行仿佛一切顺利。但随后systemctl start myapp却报错Failed to load myapp.service: No such file or directory。你反复确认文件存在、权限正确、语法无误百思不得其解。问题在于daemon-reload并非总是“全量刷新”它有一个鲜为人知的缓存机制——systemd 会跳过那些未被标记为“dirty”的单元文件。systemd 在内存中维护一个单元文件的“修改时间戳mtime”快照。当daemon-reload执行时它只重新解析那些 mtime 比内存快照更新的文件。但如果你通过cp、mv或编辑器“另存为”方式覆盖文件某些文件系统如 NFS或编辑器如 vim 的 swap 文件机制可能导致 mtime 未更新或更新时间早于 systemd 记录的快照。此时daemon-reload会静默跳过该文件内存中仍是旧定义。我遇到的真实案例运维同事用scp将新服务文件传到服务器执行daemon-reload后服务无法启动。strace systemctl daemon-reload显示它根本没open()那个文件。最终发现scp默认不保留时间戳新文件的 mtime 比旧文件还早。解决方案是scp -p保留属性或touch /etc/systemd/system/myapp.service强制更新时间戳。更隐蔽的风险来自systemctl edit。如前所述它创建override.conf但若你手动删除该文件daemon-reload不会自动清除内存中的覆盖配置——因为 systemd 认为“文件被删”不等于“配置失效”它只响应“文件内容变更”。此时必须执行systemctl revert myappsystemd v240或手动rm /etc/systemd/system/myapp.service.d/override.conf daemon-reload。另一个致命误区是daemon-reload的作用域。它只重新加载/etc/systemd/system/、/run/systemd/system/和/usr/lib/systemd/system/下的单元文件但不会重新加载/etc/systemd/system.conf或/etc/systemd/logind.conf等全局配置。修改这些文件后必须sudo systemctl daemon-reload sudo systemctl restart systemd-logind或其他相关服务才能生效。为杜绝此类“静默失败”我制定了三条铁律每次修改后强制执行systemctl cat unit它会输出当前内存中加载的实际单元定义与磁盘文件逐行比对一眼识破 reload 是否生效批量修改时用systemctl reset-failed清除失败状态避免旧错误状态干扰新配置CI/CD 流水线中daemon-reload后必须跟systemctl is-active unit断言确保 reload 后服务定义可被识别。注意systemctl daemon-reload不会重启任何正在运行的服务它只是刷新定义。要应用新配置还需systemctl restart unit。但若新配置有语法错误restart会失败而reload不会——因此reload是安全的“预检”步骤。7. 服务日志的“黑洞”现象为什么journalctl -u nginx查不到刚发生的错误你刚刚systemctl start nginx终端显示Job for nginx.service failed但执行sudo journalctl -u nginx --since 1 minute ago却返回空。你怀疑日志被清空又试journalctl -b本次启动日志依然没有 nginx 相关条目。这不是日志丢失而是systemd-journald 的日志捕获时机问题若服务进程在 systemd 完成日志管道建立前就崩溃错误信息会直接输出到控制台并消失。systemd 启动服务的流程是fork 子进程在子进程中建立stdout/stderr到 journald 的 Unix socket 管道execExecStart指定的程序。如果ExecStart的程序如/usr/sbin/nginx在 exec 阶段就因缺失库文件、权限错误或配置语法错误而立即崩溃exit code ! 0它甚至来不及向管道写入任何日志错误信息直接由内核返回给 systemd然后被丢弃。此时journalctl自然查不到。我调试一个 Node.js 服务时屡次遭遇此问题node app.js因package.json缺失main字段而快速退出journalctl一片空白。解决方案是强制让进程“慢下来”给日志管道建立留出时间[Service] # 在启动前插入 100ms 延迟确保日志管道就绪 ExecStartPre/bin/sleep 0.1 ExecStart/usr/bin/node /opt/myapp/app.js更优雅的方法是使用StandardOutputjournalconsole和StandardErrorjournalconsole强制将早期错误同时输出到 journal 和控制台。但最根本的解决之道是在ExecStartPre中做前置检查[Service] # 检查 Node.js 版本 ExecStartPre/bin/sh -c node --version | grep -q v18 || { echo Node.js 18 required; exit 1; } # 检查配置文件存在性 ExecStartPre/bin/sh -c test -f /opt/myapp/config.json || { echo Config missing; exit 1; } ExecStart/usr/bin/node /opt/myapp/app.js这样任何前置失败都会产生清晰的 journal 日志且ExecStartPre的错误会原样记录。另一个日志黑洞是SyslogIdentifier的误导。你可能在服务文件中设SyslogIdentifiermyapp以为journalctl -t myapp就能查到所有日志。但SyslogIdentifier只影响通过syslog()系统调用写入的日志而stdout/stderr的日志标识符默认是服务名myapp.service。因此journalctl -u myapp.service才是正解。-t参数适用于传统 syslog 场景与 systemd journal 的原生日志流无关。最后别忘了日志存储策略。journalctl默认只保存本次启动日志/run/log/journal/重启后清空。要永久保存需启用持久化sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal然后journalctl --list-boots就能看到历史启动记录journalctl -u nginx --boot-1查看上一次启动的日志。提示journalctl -u unit -o json-pretty以 JSON 格式输出日志便于用jq工具解析例如提取错误级别journalctl -u nginx -o json-pretty | jq .PRIORITY 33 表示 ERR。8.systemctl list-units --typeservice的“幽灵服务”如何识别被mask或static的单元执行systemctl list-units --typeservice你看到一长串服务其中docker.service状态是loaded (masked)而gettytty1.service是loaded (static)。它们既不显示active也不显示inactive像幽灵一样悬浮在列表中。这不是 bug而是 systemd 对单元文件“加载状态”的精细分类直接反映其可操作性。list-units的LOAD列有四种值loaded单元文件被成功解析可被start/stopmasked单元文件被符号链接到/dev/null完全禁止启动start命令会报Unit unit is masked.static单元文件存在但没有[Install]段无法enable只能手动startnot-found单元文件不存在但可能被其他单元Wantssystemd 会尝试加载却失败。masked是最高级别的禁用。systemctl mask docker会执行ln -sf /dev/null /etc/systemd/system/docker.service。要解除必须systemctl unmask docker而非简单删除链接——unmask会恢复原始文件的符号链接或复制备份。static服务则常见于getty.service虚拟终端、systemd-journald.service日志守护进程等核心组件它们由 systemd 自动管理无需用户enable。我曾因误判static服务而浪费数小时在调试一个串口通信服务时systemctl list-units | grep serial显示serial-gettyttyS0.service loaded (static)我以为它没启动于是systemctl enable serial-gettyttyS0.service结果报错The unit files have no [Install] section.。查阅文档才明白符号表示模板单元serial-getty.service是模板serial-gettyttyS0.service是实例其启用方式是systemctl enable serial-gettyttyS0.service—— 但serial-getty.service本身是static因为它不需要enable只需start实例即可。识别“幽灵服务”的实战技巧对masked服务systemctl status unit会明确提示Loaded: loaded (masked)且start失败对static服务systemctl is-enabled unit返回staticenable失败但start成功对not-found服务systemctl cat unit报错No files found for unit但list-dependencies可能显示它被其他单元引用。要彻底清理幽灵服务关键是理解其来源masked服务通常由管理员主动禁用或安全加固脚本生成static服务是 systemd 发行版预置的不应删除not-found服务多因拼写错误或依赖声明冗余可grep -r unit /usr/lib/systemd/system/追踪源头。注意systemctl list-unit-files显示的是“所有已知单元文件”的启用状态enabled/disabled/static/masked而list-units显示的是“当前内存中加载的单元”的运行状态。二者视角不同需结合使用。9.systemctl的“权限幻觉”为什么sudo systemctl start有时仍失败你以 root 用户登录执行sudo systemctl start myapp却收到Failed to start myapp.service: Access denied。你确认服务文件权限是644/opt/myapp目录属于root:rootUserroot一切看起来天衣无缝。问题出在 systemd 的D-Bus 接口访问控制——systemctl本质是通过 D-Bus 与systemd守护进程通信而 D-Bus 有自己的权限策略与 Linux 文件权限完全独立。systemd 的 D-Bus 策略文件位于/usr/share/dbus-1/system.d/org.freedesktop.systemd1.conf其中关键规则是policy userroot allow ownorg.freedesktop.systemd1/ allow send_destinationorg.freedesktop.systemd1/ /policy这允许 root 用户拥有和发送消息到 systemd 的 D-Bus 服务。但若你通过su -切换到 root某些发行版的su会重置XDG_RUNTIME_DIR环境变量导致systemctl无法连接到 root 用户的 D-Bus 会话总线位于/run/user/0/bus。此时systemctl会退回到系统总线但若策略未授权就会Access denied。我遇到的典型场景是在 Jenkins 服务器上Jenkins 以jenkins用户运行构建脚本中sudo systemctl start myapp失败。sudo默认不传递环境变量XDG_RUNTIME_DIR为空systemctl无法定位 D-Bus socket。解决方案是# 在 Jenkins 脚本中显式设置 export XDG_RUNTIME_DIR/run/user/0 sudo systemctl start myapp或更稳妥地用sudo -E保留环境sudo -E systemctl start myapp另一个权限幻觉来自systemd的RestrictAddressFamilies安全选项。若服务文件中设置了[Service] RestrictAddressFamiliesAF_UNIX AF_INET则该服务进程被禁止使用AF_INET6IPv6地址族。若应用代码尝试监听::1会因权限不足崩溃systemctl status显示failed但错误日志可能只写bind: Permission denied不提RestrictAddressFamilies。此时需检查systemctl show --propertyRestrictAddressFamilies myapp确认限制。最后systemctl的--no-block选项常被误解。systemctl --no-block start myapp并非“后台启动”而是“不等待启动完成就返回”它仍会通过 D-Bus 发送启动请求