开机自启的几种方式与推荐顺序

开机自启的方式不止一种：把命令塞进 rc.local、写一个 systemd 服务、用 crontab 的 @reboot。三种都能用，可靠性和维护成本差别不小，按维度过一遍。 ## systemd：现在的正路 主流发行版已全面用 systemd 管理启动，unit 文件是官方推荐位置，依赖顺序、重启策略、日志全都有： ``` # /etc/systemd/system/myapp.service [Unit] After=network.target [Service] ExecStart=/usr/local/bin/myapp Restart=on-failure User=appuser [Install] WantedBy=multi-user.target ``` 启用三部曲：systemctl daemon-reload、systemctl enable --now myapp、systemctl status myapp 确认状态。进程崩了自动拉起，journalctl -u myapp 看日志。自己写的 unit 一律放 /etc/systemd/system，优先级高于发行版自带的 /usr/lib/systemd/system，同名时以你的为准。排错时用 systemctl cat 服务名，能看到实际加载的是哪份文件、来自哪个路径。 ## rc.local：能用但已是配角 老习惯是把命令写进 /etc/rc.local。现状是 CentOS 7 以后该文件默认不存在，需手工创建并加执行权限，漏了 chmod +x 是最常见的"写了却不执行"的原因，Ubuntu 上同样要手动放行。它适合一两行点火式命令，比如临时挂载、拉起一个无状态脚本，但没有进程守护，挂了就挂了，日志也得自己想办法。真要用它，文件末尾必须保留 exit 0 一行，缺了它整个脚本不会执行。能用，别依赖。 ## cron @reboot：轻量补充 crontab 里一行： ``` @reboot sleep 30 && /opt/scripts/init.sh ``` 适合不值得写 unit 的小任务，用户级配置也方便。缺点是时序不可控，网络、磁盘就绪的先后要自己 sleep 处理；而且错过就是错过，机器不重启它永远不跑，任务的幂等性要自己保证。核对自启是否生效，可以拿 who -b 查上次开机时间，对照任务的日志时间点。还有个隐蔽坑：@reboot 的任务失败不会有任何提示，关键任务记得自己写日志。 ## 按场景给结论 常驻服务一律 systemd unit；一两行启动命令且无所谓守护的，@reboot 或 rc.local 均可，推荐 @reboot，不碰系统文件、迁移方便。机器交接时用 systemctl list-unit-files --state=enabled 盘点全部自启项，多余的关掉，交接时把这份清单同步进文档。判断标准就一条：这东西挂了需不需要被自动拉起？需要，就 systemd。