Supervisord静默失败主因是配置错误，需确保command为绝对路径、directory存在且可访问、日志父目录手动创建、user权限合法四大硬性条件全部满足。

systemd 服务配置必须设 Restart=always 且禁用启动频率限制

现代 Linux 发行版（CentOS 7+/Ubuntu 16.04+）默认用 systemd 管理服务，它原生支持崩溃后拉起。但很多人配了 Restart=always 却发现重启不生效，问题常出在默认的启动频率限制上。

• StartLimitInterval=0 必须显式设置，否则 systemd 默认 10 秒内最多允许 5 次启动，超限后直接拒绝后续尝试，日志里只显示 start request repeated too quickly
• RestartSec=5 建议设为 3–10 秒，避免进程刚退出又立刻拉起，造成 CPU 或磁盘打满
• Type=simple 适用于前台运行程序；如果程序自己 fork() 后退出父进程（即 daemonize），得改用 Type=forking，否则 systemd 会误判为已退出
• User= 字段指定运行用户后，确保该用户对 ExecStart 路径、工作目录、日志路径都有读写权限，否则启动失败且无明确报错

supervisord 配置静默失败的四个硬性条件

Supervisord 不报错、不写日志、supervisorctl start xxx 返回 ERROR (no such process) —— 这不是 bug，是配置没满足基础前提。它不会帮你创建目录或校验权限，全靠你手动落实。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• command 必须是绝对路径，不能含 ~ 或 $HOME；Java 启动要写全 /usr/bin/java，Python 要写 /usr/bin/python3
• directory 对应路径必须真实存在，且 user 对该目录有 r-x 权限（能 cd 进去）
• stdout_logfile 和 stderr_logfile 的**父目录必须提前 mkdir -p 创建好**，supervisord 只建文件，不建目录
• user 字段若指定，该用户必须能执行 command 中的二进制，并有权限访问 directory 和日志路径；留空则用 supervisord 主进程用户（通常是 root）

autorestart=true 不触发重启？先确认进程是否真“退出”

autorestart=true 只响应「进程 exit」事件，不是所有“挂了”都算退出。比如：

• 程序被 OOM Killer 杀掉时，内核直接终止进程，不走正常退出流程，supervisord 无法捕获 —— 此时需配合 cgroup memory limit 或应用层内存监控
• 程序卡死（CPU 占满或死锁），但进程仍在运行，supervisord 认为它“活着”，不会重启 —— 需加外部健康检查（如 HTTP /health 探针 + curl -f 脚本轮询）
• 程序收到 SIGTERM 后优雅关闭并 exit，这算正常退出；但若收到 SIGKILL（如 kill -9），进程被强制终止，supervisord 仍会按 autorestart 策略处理
• 推荐改用 autorestart=unexpected，它只在非零退出码、信号终止等异常场景重启，避免正常 shutdown 后又被拉起

pm2 自动重启失效常见原因

Node.js 应用常用 pm2，但它不是万能守护：系统级 OOM、ulimit 限制、或配置疏漏都会导致重启失败。

• autorestart: false 是默认值，必须显式设为 true 才启用自动拉起
• 应用启动慢（如连接数据库超时），min_uptime 设太小（如 1000）会导致刚起来就被判定为“不稳定”，计入重启计数
• max_restarts 默认是 15，单位时间（默认 30 秒）内超限后 pm2 会停止尝试，需结合 restart_delay（建议 3000ms）控频
• 生产环境务必关掉 watch: true，否则文件变更会触发热重载，和自动重启逻辑冲突；用 ignore_watch 显式排除 node_modules 和日志目录

真正容易被忽略的是：**重启本身可能掩盖更深层问题**。比如频繁重启往往意味着内存泄漏、未捕获异常或依赖服务不可用。光配好守护机制不够，得看 journalctl -u myapp 或 supervisord 日志里的退出码和堆栈，才能判断是该修代码，还是调参数。