如何在Linux中配置启动脚本并行执行

启动脚本本身不能并行执行，真正并行的是其启动的子任务；推荐用systemd将各任务封装为独立service实现可控并发，避免在rc.local中简单用&和wait导致的环境、等待、日志等问题。

启动脚本本身不能“并行执行”——它是一段被调用的代码，真正能并行的是其中启动的子任务。你要的不是让多个启动脚本同时跑，而是让单个启动脚本内部高效并发地拉起多个服务或任务。

为什么直接在 rc.local 或 systemd service 里写 & 不可靠

很多人在 /etc/rc.local 末尾写：./task1.sh & ./task2.sh & wait，以为这就实现了并行。但问题在于：

• rc.local 在 systemd 系统中默认已禁用，即使启用，它的执行环境极简（PATH=/usr/bin:/bin，无用户 shell 初始化）
• wait 在非交互式 shell 中可能失效，尤其当子进程 fork 后又 daemonize（如 nginx、redis），wait 根本等不到它们
• 没有超时控制、失败隔离和日志区分，一个任务卡死，整个启动流程可能挂住

systemd service 中正确启用并行子任务

如果当前环境是现代 Linux（默认采用 systemd），更稳妥、也更清晰的做法，是把每个需要并行执行的任务分别封装成独立的 .service 文件，然后通过 WantedBy=multi-user.target 统一启用。原因也不复杂：systemd 本身就支持并行启动，只要没有额外声明 After= 或 Requires= 这类依赖关系，相关任务就可以同时拉起。

例如，你有两个监控脚本 /usr/local/bin/monitor-net.sh 和 /usr/local/bin/monitor-disk.sh，分别建两个 service：

[Unit]
Description=Network monitor
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/monitor-net.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]
Description=Disk monitor
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/monitor-disk.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

接着执行：sudo systemctl enable monitor-net.service monitor-disk.service。启用之后，systemd 会把这两个服务并行拉起；同时，它们各自都有独立日志（journalctl -u monitor-net），重启策略和依赖关系也能分别控制，管理起来会更清晰。

必须用单个脚本兜底时，如何安全并行

某些场景下（比如 legacy 兼容、快速验证），你确实需要一个 shell 脚本内部并发执行多个命令。这时要绕过 rc.local 的缺陷，改用 systemd 的 Type=forking 或 Type=exec + 显式进程管理：

• 用 timeout 包裹每个任务，防止单个卡死拖垮整体：timeout 30s ./task1.sh > /var/log/task1.log 2>&1 &
• 记录 PID 并做基础等待：PID1=$!; timeout 45s wait $PID1 || echo "task1 timed out"
• 所有路径必须绝对——/usr/bin/python3 不要写成 python3；日志路径也得写死，如 /var/log/myboot-task.log
• 避免在脚本里调用 sudo 或 su：systemd service 可通过 User= 和 Group= 指定运行身份，shell 脚本里硬切用户极易失败

真正容易被忽略的点是：并行不等于“快”，而是“可控的并发”。盲目堆 & 可能压垮系统资源，而没日志、没超时、没 PID 跟踪的并行，上线后根本没法 debug。优先拆成多个 systemd unit，比在一个脚本里手工管理 5 个后台进程靠谱得多。