现代linux必须用systemd管理服务，/etc/rc.local在ubuntu 20.04+已默认禁用，sysvinit仅适用于centos 6等老系统；.service文件须置于/etc/systemd/system/、以.service结尾、execstart用绝对路径、显式声明环境变量、避免nohup&后台化、推荐type=simple+restart=always，并在修改后执行sudo systemctl daemon-reload。
现代 Linux（CentOS 7+、Ubuntu 16.04+、Debian 8+）必须用 systemd，/etc/rc.local 在 Ubuntu 20.04+ 已默认禁用，SysVinit 方式（chkconfig / update-rc.d）只适用于老系统（如 CentOS 6），混用会失败。
怎么写一个能被 systemd 管理的 .service 文件
关键不是“能不能跑”，而是“能不能被 systemd 正确识别和重启”。服务文件必须放在 /etc/systemd/system/ 下，且命名以 .service 结尾。
-
ExecStart必须是绝对路径；如果启动脚本依赖环境变量（如JAVA_HOME或PATH），得显式声明：Environment="JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64" - 不要在
ExecStart里直接写nohup ./myapp.sh &——systemd会认为进程立即退出，导致Active: failed；应改用Type=simple+ 后台化逻辑，或更稳妥地用Type=forking并配合PIDFile= -
User和Group建议显式指定（如User=www-data），避免以 root 运行带来权限风险 - 若程序本身不 daemonize，推荐加
Restart=always和RestartSec=3，否则崩溃后不会自动拉起
systemctl enable 失败的常见原因
执行 sudo systemctl enable myapp.service 报错，多数不是语法问题，而是路径或权限卡住：
- 文件没放在
/etc/systemd/system/（放错到/lib/systemd/system/可能被包管理器覆盖；放错到用户目录下则完全不可见） - 文件没有读权限：
sudo chmod 644 /etc/systemd/system/myapp.service - 修改过 service 文件后没重载配置：
sudo systemctl daemon-reload缺失这步，enable会静默失败或启用旧版本 - 服务名和文件名不一致（比如文件叫
myapp.service，却执行systemctl enable myappd.service）
老系统（CentOS 6 / Ubuntu 14.04）用 chkconfig 配置自启时必须加三行注释
在 /etc/init.d/myapp 脚本头部，这三行不是可选注释，而是 chkconfig 解析运行级别和优先级的硬性要求：
# chkconfig: 35 20 80 # description: My custom service # processname: myapp
缺任意一行，chkconfig --add myapp 会报 service myapp does not support chkconfig。其中 35 表示仅在运行级别 3 和 5 启动，20 是启动顺序（数字越小越早），80 是关闭顺序。
/etc/rc.local 还能用吗？怎么避坑
它在部分发行版（如 CentOS 7）中仍存在但默认不执行；Ubuntu 20.04+ 已移除该机制。即使可用，也极易出问题：
- 必须在
exit 0之前添加命令，否则被忽略 - 所有命令需绝对路径（
/usr/bin/python3，不能只写python3） - 脚本本身要有执行权限：
sudo chmod +x /etc/rc.local - 如果命令阻塞（如没加
&的前台服务），系统可能卡在启动界面——这是最常被忽略的致命点
真正需要兼容多版本或临时调试时，/etc/rc.local 才是备选；生产环境请坚持用 systemd，它的依赖控制、日志集成和状态反馈远非 rc.local 可比。
