启动脚本本身不能并行执行，真正并行的是其启动的子任务；推荐用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 个后台进程靠谱得多。
