pid文件校验需先清洗空格再检查纯数字且非0、不超pid_max；进程存活须ps精确匹配二进制名，可选端口监听验证；pid文件应由进程就绪后写入并sync落盘；重启优先发usr2/hup信号，仅无pid或死亡时才全新启动。
只读 PID 文件内容，不假设它一定有效
PID 文件只是个文本文件，内容可能为空、含非法字符、指向已消亡进程，甚至被其他程序覆盖。脚本第一步永远是：读取后立刻清洗并校验格式。
- 用
cat "$PIDFILE" | tr -d '[:space:]'去首尾空格和换行，避免kill -0 ""报错 - 检查结果是否为纯数字：
[[ "$pid" =~ ^[0-9]+$ ]] || return 1 - 拒绝接受
0或超大值（如 > 65535）——内核实际 PID 范围受/proc/sys/kernel/pid_max限制，但常见服务 PID 一般
用 kill -0 + ps -o comm= -p 双重验证进程真实存活
kill -0 $PID 只检查进程是否存在且调用者有权限探测，不发信号；但无法区分进程是否僵死、是否被复用。必须叠加命令名比对。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
kill -0 "$pid" 2>/dev/null失败 → 进程已消亡 - 成功后执行
ps -o comm= -p "$pid" 2>/dev/null，输出必须严格等于预期二进制名（如myapp-master），不能只用grep myapp——否则可能匹配到myapp-worker或日志里的字符串 - 若需更高置信度，加一层端口检查：
lsof -p "$pid" -a -i :8080 | grep LISTEN，但会引入lsof依赖，非必需场景可省
写 PID 文件必须在进程真正就绪后，且确保落盘
很多脚本在 nohup ./bin/master & echo $! > pidfile 后就认为完成，但此时进程可能还没初始化完监听套接字，或刚 fork 就崩溃，PID 文件却已残留。
- Master 进程自身应在完成全部初始化（如绑定端口、加载配置、连通数据库）后再写 PID 文件，而不是由启动脚本代劳
- 若必须由脚本写，务必用
echo "$!" > "$PIDFILE" && sync "$PIDFILE"，尤其在容器或 tmpfs 环境下，避免因缓存未刷导致文件丢失 - 写入前先
rm -f "$PIDFILE"，防止旧 PID 干扰；权限设为644或600，避免被非属主篡改
重启逻辑必须区分平滑重启与强制拉起
直接 kill -9 再 nohup 启动看似简单，但会丢连接、中断事务、触发客户端重试风暴。真正的维保要按进程行为分层处理。
- 健康时优先发
kill -USR2 "$pid"或kill -HUP "$pid"（取决于应用是否支持热重载） - 仅当
is_healthy返回 false 且无可用 PID 时，才走全新启动流程，并记录restart_reason="no_pid_or_dead"到日志 - 启动后需等待几秒再验证，例如
sleep 2 && is_healthy，避免检查过早返回假阴性
pidof myapp 或 ps | grep，基本等于没做验证。
