systemd下/etc/rc.local默认不生效，因rc-local服务被禁用；应创建systemd服务单元，确保脚本可执行、用绝对路径、正确配置unit[install]，并用journalctl查日志排错。

systemd 是当前绝大多数发行版的默认初始化系统，直接往 /etc/rc.local 里写命令大概率不生效——不是你脚本错了，是没人读它。

为什么 /etc/rc.local 不再自动执行

systemd 默认禁用 rc-local 服务，即使文件存在，systemctl status rc-local 也常显示 inactive (dead)。这不是配置遗漏，而是设计变更：systemd 不再默认扫描该文件。

• 运行 ps -p 1 -o comm= 确认 init 系统，若输出 systemd，就别依赖 rc.local 的“自动”行为
• /etc/rc.local 文件权限必须是可执行（chmod +x /etc/rc.local），否则 systemd 即使启用也会跳过
• 脚本内所有命令必须使用绝对路径，PATH 在早期启动阶段极简，ls 或 echo 可能找不到

用 systemd 创建专属服务单元（推荐）

这是最可控、可监控、支持依赖管理的方式。关键不是“让脚本跑起来”，而是“把它变成一个被 systemd 管理的服务”。

• 脚本本身需有 #!/bin/bash 开头，且用 chmod +x /path/to/your_script.sh 赋予执行权
• 服务文件放在 /etc/systemd/system/your_script.service，内容至少包含：[Unit]（描述和依赖）、[Service]（ExecStart 必填，建议加 Restart=always 和 RestartSec=5）、[Install]（WantedBy=multi-user.target）
• 若脚本需以非 root 用户运行，显式添加 User=youruser；否则默认以 root 执行，可能引发权限或路径问题
• 改完必须执行 systemctl daemon-reload，否则 enable 或 start 会报 “unit not found”

systemctl enable 后仍不执行？检查这三点

启用服务 ≠ 立即运行，只是注册了开机触发条件。常见卡点不在配置语法，而在环境假设。

• journalctl -u your_script.service -n 50 --no-pager 查日志，90% 的失败原因在日志里：如 Permission denied（路径无读/执行权）、No such file or directory（解释器路径错或脚本路径错）、Failed at step EXEC spawning（ExecStart 指向了目录或没权限的文件）
• 脚本中若依赖网络（如 curl 远程 API）、数据库（如 mysql 命令）、或挂载点（如 /mnt/data），需在 [Unit] 加 After=network-online.target 或 After=mysqld.service，并加 Wants=network-online.target
• 避免在脚本里用 cd 切换相对路径后执行命令——systemd 启动时工作目录不确定，一律用绝对路径，或在脚本开头加 cd /your/script/dir || exit 1

临时验证比重启更快：用 systemctl start 手动触发

每次改完配置，先手动启动一次，比反复重启机器高效得多。成功与否立刻可见，且日志上下文更干净。

• 执行 systemctl start your_script.service，立刻跟 systemctl status your_script.service 看状态是否为 active (running)
• 若状态是 failed，journalctl -u your_script.service 输出的就是最后一次失败的完整堆栈，比开机日志更容易定位
• 确认手动能跑通后，再执行 systemctl enable your_script.service 注册开机自启，避免把配置错误带进启动链

真正容易被忽略的是：systemd 服务默认没有终端（tty）和完整用户环境，$HOME、$PATH、shell 别名、甚至某些动态库路径都和你登录后不同。不要假设“我在终端里能跑，开机就能跑”。