宝塔未被识别为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’”。
