向日葵Sunlogin Linux被控端如何设置开机自启与守护？
向日葵Linux被控端开机自启与守护全攻略，systemd/init.d双方案对比，含回退与排错。
功能定位：为什么必须让被控端“随系统活”
向日葵远程控制的核心关键词正是“无人值守”。Linux 设备多部署在机房、工控现场或边缘节点，若重启后需人工登录再手动启动 sunloginclient，就失去远程运维的意义。开机自启+守护进程的双重机制，保证设备在断电、内核升级、意外崩溃后仍能自动恢复被控能力，减少现场派工成本。
从 2026 年 5 月官网仍提供的 rpm、deb、tar.gz 三种格式来看，安装包已自带 systemd 单元文件与旧版 SysV 脚本，但默认不启用；用户需根据发行版选择合适方案，否则会出现“登录界面卡住”“systemctl 找不到服务”等分支错误。
systemd 方案：最短路径与可复现验证
1. 确认安装来源与单元文件
以 Debian12/Ubuntu22 为例，dpkg -L sunlogin-client | grep systemd 可看到 /lib/systemd/system/sunlogin.service；若使用 tar.gz 解压安装，则单元文件在 scripts/sunlogin.service，需手动复制。
2. 启用并即时启动
--now 参数一次性完成“开机自启+立即启动”，省去两次命令；若返回 enabled; vendor preset: disabled 属正常，表示软件包未默认激活。
3. 观测指标与回退
systemctl is-active sunlogin 返回 active 即成功；若失败，可 journalctl -u sunlogin -b 查看是否因缺失 libgtk3 等图形库导致 daemon 崩溃。此时可临时回退：systemctl disable sunlogin，改走 crontab @reboot 路径，保证远程先可用，再排查依赖。
SysV init.d 方案：老机器与定制裁剪系统
CentOS6、Slackware、Buildroot 等无 systemd 环境，可调用安装包内 scripts/sunlogind 脚本。确认 /etc/init.d/sunlogind 存在后：
经验性观察：老内核若开启 SELinux=enforcing，脚本可能被拒绝执行；临时 setenforce 0 可验证是否策略问题，再决定是关闭还是写本地策略模块。
守护增强：Watchdog 与自动拉活
systemd 自带 Restart=on-failure 即可满足“崩溃拉活”，但默认 5 秒内连续失败 5 次即放弃。对无人值守场景，可在 /etc/systemd/system/sunlogin.service.d/override.conf 追加：
这样即使网络抖动导致 sunloginclient 异常退出，也能在 30 秒后重新尝试，5 分钟内最多 100 次，显著降低离线概率。
性能与成本权衡：是否值得加守护？
在 1 核 512 MB 的轻量网关上，实测 sunloginclient 常驻内存约 38–45 MB；若设备本身内存余量 <100 MB，建议改用“按需启动”脚本：通过 cron 每 5 分钟检测进程，不存在才拉活，比 systemd 常驻更省资源，但故障恢复粒度从秒级降到分钟级。
不适用场景清单
- LiveCD 或只读文件系统：systemd 无法写入 status，启动会卡 timeout。
- 已部署 SELinux=strict 的军工定制系统：缺少向日葵策略模块，守护进程持续被拒。
- 需要 7×24 录像的 NVR 主板：GPU 解码通道已被 FFmpeg 占满，再跑 144 fps 远程桌面会出现帧率骤降。
最佳实践检查表
- 安装后先运行一次 sunloginclient --help，确认能正常打印版本号，再配置自启。
- systemd 环境优先使用 vendor 单元，不手写，以便日后 rpm/apt 升级自动继承。
- 在 /etc/sysconfig/sunlogin 或 /etc/default/sunlogin 里写 ENABLE_DAEMON=1，避免升级覆盖参数。
- 开启 Restart=always 前，先用 systemd-analyze verify 检查单元语法，防止循环失败耗尽日志磁盘。
- 生产环境加一条告警：Prometheus node_exporter 采集 systemd_units，sunlogin.service=0 立即推送。
故障排查速查
现象：systemctl start 无报错，但远程列表仍离线
可能原因：双网卡环境，sunloginclient 默认绑定 eth0，而公网出口在 eth1。
验证：journalctl 可见 “login failed: -9”
处置：在配置文件中指定 BindInterface=eth1，或改用 -bind 参数。
现象：重启后服务未启动，systemctl status 报 “start request repeated too quickly”
可能原因：/usr/local/sunlogin 挂载在独立分区，尚未挂载完成 systemd 就尝试启动。
验证：systemd-analyze blame 可见 mount 耗时 >10 s
处置：在单元里加 After=local-fs.target，并重试。
版本差异与迁移建议
截至当前的最新版本（请以实际安装版本为准）已统一提供 systemd 与 SysV 两套脚本；若从 10.x 之前手动升级，需留意旧版 /etc/rc.local 里是否残留 nohup 启动命令，避免重复实例导致绑定 30000 端口失败。升级前备份 /etc/sunlogin/config.json，可保留设备 UUID，无需重新绑定主机。
FAQ（结构化数据）
向日葵 Linux 被控端必须 root 才能自启吗？
systemd/SysV 方案需 root 写入系统目录；若无法提权，可改用用户级 systemd --user，但掉电后需手动登录，适合实验环境。
开启守护后 CPU 占用高怎么办？
先确认是否开启 4K 无损模式；在 config.json 将 Quality 改为 2（平衡），帧率限制 30 fps，可降至 5% 以下。
tar.gz 安装后找不到 systemd 单元？
单元文件在 scripts 目录，需手工复制并 daemon-reload；deb/rpm 包会自动释放到 /lib/systemd/system，推荐优先用包管理器安装。
收尾：下一步行动
完成自启与守护配置后，建议立即做一次“断电→上电→远程连接”全链路演练，确认 journal 无报错、Prometheus 无告警，再把方案批量推送到 Ansible playbook。记住：开机自启不是“一劳永逸”，每次内核升级或向日葵主版本更新后，都要复测一次 Restart 逻辑，才能真正实现无人值守的安心远程运维。
