启动脚本本身不能并行执行，真正并行的是其启动的子任务；推荐用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：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
[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 个后台进程靠谱得多。
