宝塔未被识别为systemd服务是因为官方安装脚本未生成btpanel.service文件,仅保留/etc/init.d/bt;需手动创建匹配启动逻辑的service文件,设type=forking、正确pidfile路径,并执行daemon-reload和enable才能真正启用自启。

确认宝塔是否真被识别为 systemd 服务
很多用户执行 systemctl is-enabled bt 或 systemctl is-enabled btpanel 返回 disabled 或直接报错 No such file or directory,根本原因不是配置错了,而是压根没创建 service 文件——宝塔官方安装脚本在 CentOS Stream 10、部分新版 CentOS 7/8 上默认不生成 .service 单元,只留了 /etc/init.d/bt 这个 SysV 脚本。
验证方法很简单:
- 运行
ls /usr/lib/systemd/system/bt*,如果无输出,说明 systemd 服务文件缺失 - 再查
ls /etc/init.d/bt,通常这个文件是存在的,说明得手动桥接 - 别信“宝塔已自动注册”,尤其在 CentOS Stream 10 上,这是已知行为(2026 年 2 月 28 日 bug 反馈确认)
手动创建正确的 btpanel.service 文件
不能直接复制网上五花八门的模板,关键要匹配宝塔实际启动逻辑。它不直接跑 bt.py,而是调用 /etc/init.d/bt start,且依赖 PIDFile 判断状态。错误地写成 Type=simple + ExecStart=/www/server/panel/bt.py 会导致启动成功但状态始终显示 inactive(因为没写 PID 文件或没 fork)。
正确做法是新建 /usr/lib/systemd/system/btpanel.service,内容如下:
[Unit] Description=Bt-Panel Service After=network.target [Service] Type=forking ExecStart=/etc/init.d/bt start ExecReload=/etc/init.d/bt reload ExecStop=/etc/init.d/bt stop PIDFile=/www/server/panel/logs/panel.pid Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
-
Type=forking是必须项,否则 systemd 无法跟踪后台进程 -
PIDFile路径必须和宝塔真实生成的一致,查看可用ls /www/server/panel/logs/panel.pid - 别把
WantedBy写成graphical.target,宝塔不需要图形界面,multi-user.target才是标准服务器运行级
启用并验证自启逻辑是否真正生效
写完 service 文件只是第一步,systemd 不会自动加载。漏掉重载或 enable,等于白配。
- 执行
systemctl daemon-reload—— 没这步,systemd 根本不知道新文件存在 - 执行
systemctl enable btpanel—— 注意不是bt,服务名以文件名(不含 .service)为准 - 检查是否成功:
systemctl is-enabled btpanel应返回enabled;systemctl status btpanel应显示 active (running) - 终极验证:执行
reboot,重启后立刻跑ss -tuln | grep :8888,有监听才代表真自启成功
CentOS Stream 10 用户特别注意路径与权限陷阱
Stream 10 默认禁用 rc-local.service,且对 /etc/init.d/ 脚本兼容性更差。这时候如果还沿用老办法往 /etc/rc.local 里加 /etc/init.d/bt start,大概率失败——因为 rc-local.service 本身没启用,或者脚本执行时环境变量缺失(比如没加载 /etc/profile)。
- 先确认
rc-local状态:systemctl is-enabled rc-local,若为disabled,需先systemctl enable rc-local - 但更推荐彻底放弃
rc.local,专注修好 systemd 服务——它才是 Stream 10 的正统机制 - 另外,Stream 10 的 SELinux 策略可能拦截
/etc/init.d/bt调用 Python,如遇启动卡住,临时关 SELinux 测试:setenforce 0,确认是策略问题再针对性放行
最常被跳过的一步是检查 panel.pid 文件权限:如果 /www/server/panel/logs/ 目录属主不是 root,或 panel.pid 被删过但没重建,systemd 会因找不到 PID 文件而反复 restart,日志里只显示 “Failed with result ‘protocol’”。










