Linux脚本开机自启设置教程

systemd 是当前唯一能对日志和依赖关系实现精准控制的方案。其他方法要么默认禁用（如逐渐被遗忘的 rc.local），要么根本不适合开机自启场景（如 /etc/profile.d/）。要实现稳定、可控、可查的开机自启，必须依赖 systemd。

许多人在 /etc/rc.local 中写入命令后失败，首先会检查脚本语法和权限。但很可能脚本本身没有错误，而是 systemd 根本未执行它。

为何直接往 /etc/rc.local 写入命令常失败

问题不在于脚本编写错误，而在于 systemd 默认不执行该文件。即使文件存在、包含 #!/bin/bash、并已执行 chmod +x，rc-local.service 依然处于 inactive (dead) 状态。这是设计特性，并非缺陷。

• /etc/rc.local 在 systemd 系统中仅作为兼容层存在，必须手动启用对应 service 才能触发。
• 其执行环境极为简陋：PATH 仅包含 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin，未加载用户 profile，且不保证网络已就绪。
• 若脚本中使用 sudo、systemctl、su - user -c 等需要交互的命令，将直接卡住或无声失败。
• 如果脚本依赖 DNS 或远程服务，仅写 After=network.target 不够，需使用 network-online.target 才能保障执行时机。

使用 systemd 创建 .service 文件的最小可行配置

避免照搬冗长模板，只保留必要字段。以下是一个能立即生效的最简配置：

[Unit]
Description=My Startup Script
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/myscript.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

• Type=oneshot 适用于一次性脚本；若需长期运行进程（如 Python Web 服务），应改为 Type=simple，并确保进程不自行 daemonize。
• ExecStart= 必须使用绝对路径，不能使用 ~ 或 $HOME 等变量。
• RemainAfterExit=yes 可使服务状态保持 active，便于通过 systemctl is-active 判断是否已执行。
• 若要以非 root 用户运行，添加 User=deploy 一行，避免在脚本中使用 su 绕过。

启用后如何验证是否成功执行

不要急于重启，先完成以下验证：

• 重载配置：systemctl daemon-reload
• 启用开机自启：systemctl enable myscript.service
• 立即启动并跟踪输出：systemctl start myscript.service && journalctl -u myscript.service -n 20 -f
• 检查注册状态：systemctl is-enabled myscript.service 应返回 enabled
• 查看实际启动时机：systemctl list-dependencies --after myscript.service，确认其在 network 之后执行

@reboot crontab 和 ln -s /etc/init.d 的适用边界

这些方法并非替代方案，而是各有明确限制的备选：

• @reboot 由 cron 触发，仅对指定用户生效（sudo crontab -e 为 root，crontab -e 为当前用户），且不保证网络就绪——仅适用于纯本地、无依赖的轻量级任务。
• ln -s /etc/init.d/myscript /etc/rc.d/rc3.d/S99myscript 这种方式仅在 SysVinit 系统（如 CentOS 6、Ubuntu 14.04）中有效；在 systemd 环境下，该链接将被忽略，除非额外启用 systemd-sysv-generator 兼容层。
• /etc/profile.d/ 下的脚本仅在用户登录 shell 时被 source，系统启动时完全不执行——这也是常见的误解点。

容易被忽略的是：所有方式都要求脚本本身可执行（chmod +x），且内部调用的命令必须使用绝对路径。例如，date 在 shell 中直接输入没有问题，但在开机环境中可能因 PATH 缺失而报 command not found。