工控高频故障排查：串口无数据、程序被杀、网络断连、IO 读写异常-尧图网络科技

工控高频故障排查：串口无数据、程序被杀、网络断连、IO 读写异常

工控设备出故障不分白天黑夜，排查思路决定了你是5分钟搞定还是通宵折腾。

一、故障排查方法论

工控现场故障排查不是玄学，遵循一套方法论可以大幅缩短定位时间：

三步法：日志优先 → 隔离定位 → 逐步排除

日志优先：出问题第一时间看日志，dmesg、syslog、应用日志，80%的问题日志里都有线索
隔离定位：把问题范围缩小——是硬件还是软件？是内核还是用户空间？是网络还是本地？
逐步排除：一次只改一个变量，改完验证，不要同时动多个地方

故障发生 │ ├─→ 看日志（dmesg / syslog / 应用日志） │ │ │ ├─ 有明确报错 → 针对性修复 │ └─ 无明确报错 → 继续隔离 │ ├─→ 隔离范围 │ ├─ 硬件层？→ 换线/换板/量电压 │ ├─ 内核层？→ dmesg / 驱动日志 │ └─ 应用层？→ strace / gdb │ └─→ 逐步排除 → 修复 → 验证

二、故障1：串口无数据

串口是工控设备最常用的通信接口，"串口收不到数据"是最高频的故障之一。

2.1 排查步骤

# 第一步：确认设备节点存在ls-l/dev/ttyS*# 如果节点不存在，说明驱动没加载或DTS没配置# 第二步：检查设备权限ls-l/dev/ttyS1# crw-rw---- 1 root dialout 4, 65 Jan 1 00:00 /dev/ttyS1# 你的用户是否在dialout组？groups# 查看当前用户所属组# 如果不在dialout组：usermod-aGdialout your_user# 第三步：确认串口参数stty-F/dev/ttyS1-a# 重点看：speed(波特率), cs(数据位), parenb(校验), cstopb(停止位)# 第四步：检查DTS配置# 串口是否在设备树中启用？# 查看内核日志中串口驱动注册信息dmesg|grepttyS# [ 0.823451] ff0a0000.serial: ttyS1 at MMIO 0xff0a0000 ...# 第五步：硬件接线排查# TX-RX交叉接，GND共地，确认电平匹配（TTL/RS232/RS485）

2.2 用loopback测试隔离硬件和软件

# 短接TX和RX，自发自收测试# 先设置串口参数stty-F/dev/ttyS19600cs8-cstopb-parenb-echo# 终端1：读串口cat/dev/ttyS1&# 终端2：写串口echo"test">/dev/ttyS1# 如果终端1看到"test"，说明串口驱动正常，问题在硬件接线或对端设备# 如果看不到，说明串口驱动/硬件有问题

2.3 常见原因速查

现象	可能原因	解决方案
设备节点不存在	DTS未使能串口	修改DTS，status=“okay”
Permission denied	用户不在dialout组	usermod -aG dialout
收到乱码	波特率不匹配	stty设置正确波特率
只收不发/只发不收	TX/RX接反或硬件方向控制	检查接线，RS485检查DE/RE控制
间歇性丢数据	流控未配置/缓冲区溢出	启用硬件流控或降低波特率

三、故障2：程序被杀/OOM

工控程序莫名消失，没有core dump，没有异常日志——大概率是被OOM Killer干掉了。

3.1 确认是否被OOM

# 查看内核日志中的OOM记录dmesg|grep-i"oom\|killed process"# 典型输出：# [1234.567] Out of memory: Killed process 1234 (myapp) total-vm:512MB ...# 或者查看sysloggrep-i"oom"/var/log/sysloggrep-i"killed process"/var/log/messages

3.2 内存泄漏排查

# 方法1：top/sar持续监控内存趋势top-b-d10-p$(pidof myapp)# 如果RSS持续增长不回落，基本确认内存泄漏# 方法2：proc文件系统查看进程内存映射cat/proc/$(pidof myapp)/status|grep-i"VmRSS\|VmSize"# VmRSS: 进程实际占用物理内存# VmSize: 进程虚拟内存总大小# 方法3：valgrind定位泄漏点（开发环境）valgrind --leak-check=full --show-leak-kinds=all ./myapp# 方法4：查看进程的内存映射，找异常大块cat/proc/$(pidof myapp)/smaps|grep-E"^[0-9a-f]|RSS"

3.3 OOM防护配置

# 方法1：调整OOM分数（值越低越不容易被杀）echo-1000>/proc/$(pidof myapp)/oom_score_adj# -1000表示完全免疫OOM killer# 方法2：限制进程内存使用，防止吃光系统内存# 在程序启动脚本中设置ulimitulimit-v524288# 限制虚拟内存512MB./myapp# 方法3：systemd服务配置内存限制# /etc/systemd/system/myapp.service[Service]MemoryMax=512MMemoryHigh=400M# 超过MemoryHigh开始回收，超过MemoryMax触发cgroup OOM

3.4 代码层面预防

/* 常见内存泄漏场景：malloc后忘记free *//* 使用valgrind编译选项辅助排查 */// gcc -g -fsanitize=address -o myapp myapp.c/* 工控程序推荐做法：定期自检内存 */#include<sys/resource.h>voidcheck_memory_usage(void){structrusageusage;getrusage(RUSAGE_SELF,&usage);printf("RSS: %ld KB\n",usage.ru_maxrss);/* 超过阈值主动告警/重启自身 */if(usage.ru_maxrss>400*1024){/* 400MB */syslog(LOG_WARNING,"Memory usage too high: %ld KB, restarting",usage.ru_maxrss);/* 通知看门狗，然后主动退出，由systemd重启 */exit(1);}}

四、故障3：网络断连

4.1 排查链路

# 第一步：物理链路状态ethtooleth0# 重点看 Link detected: yes/no# Speed/Duplex是否匹配# 第二步：IP地址和路由ipaddr show eth0iproute show# 第三步：DHCP获取情况dmesg|grep-i"dhcp"# [ 15.234] eth0: DHCP lease acquired, IP=192.168.1.100# 第四步：DNS解析测试nslookupwww.baidu.com# 解析失败说明DNS配置有问题# 第五步：连通性测试ping-c4192.168.1.1# 网关ping-c48.8.8.8# 外网IPping-c4www.baidu.com# 外网域名# 第六步：端口连接状态netstat-tlnp# 监听端口netstat-tnp# 活动连接ss-tnp# netstat的现代替代

4.2 常见网络故障

场景A：DHCP超时获取不到IP

# 查看DHCP客户端日志journalctl-uNetworkManager# 或cat/var/log/syslog|grepdhclient# 解决：增大DHCP超时时间# /etc/dhcp/dhclient.conftimeout60;# 默认30秒，工控网络可能需要更长retry3;# 或者配置静态IP作为fallback

场景B：网线热插拔后网络不恢复

# 检查NetworkManager或network服务systemctl status NetworkManager systemctl status networking# udev规则配置网线插拔事件# /etc/udev/rules.d/70-persistent-net.rules# 确保MAC地址绑定正确# 手动重新获取IPdhclient-reth0&&dhclient eth0

场景C：防火墙阻断

# 查看iptables规则iptables-L-n-v# 查看nftables（新版系统）nft list ruleset# 临时清空规则测试iptables-F# 如果清空后恢复正常，说明是防火墙规则问题

五、故障4：IO读写异常

5.1 文件系统损坏

# 查看文件系统错误dmesg|grep-i"ext4\|error\|corrupt\|I/O error"# 典型错误：# EXT4-fs error (device mmcblk0p2): ext4_find_entry: reading directory# 检查并修复文件系统（需要先卸载）umount/dev/mmcblk0p2 fsck.ext4-y/dev/mmcblk0p2# 如果根文件系统损坏，需要在U-Boot中修复或重新烧录

5.2 NAND坏块

# 查看MTD设备信息cat/proc/mtd# mtd0: 00400000 00020000 "bootloader"# mtd1: 00800000 00020000 "kernel"# mtd2: 08000000 00020000 "rootfs"# 检查坏块nanddump-b/dev/mtd2# 列出坏块# 或mtd_debugread/dev/mtd200x1000 /tmp/test# 内核日志中的坏块信息dmesg|grep-i"bad block\|nand"# [ 12.345] nand: device found: bad block at 0x01200000# UBI层自动处理坏块，但坏块过多需要换芯片ubiattach /dev/ubi_ctrl-m2cat/sys/class/ubi/ubi0/bad_peb_count

5.3 设备节点消失

# 设备节点突然消失，通常是驱动崩溃或设备掉线# 查看USB设备lsusb# 查看PCI设备lspci# 查看所有已注册的字符设备cat/proc/devices# 重新加载驱动rmmod my_driver modprobe my_driver# udevadm触发设备重新枚举udevadm trigger

六、故障5：开机不启动

这是最严重的故障——设备完全无响应。

6.1 串口调试台输出分析

用USB转TTL连接设备的调试串口，观察启动日志：

U-Boot 2017.09 (Jul 13 2026) # 如果卡在这里 → U-Boot阶段问题 # 检查：Bootloader是否烧录正确？DDR初始化是否成功？ Starting kernel ... # 如果卡在这里 → 内核加载问题 # 检查：kernel.img是否完整？加载地址是否正确？ [ 0.000000] Linux version 5.10.x ... [ 2.345] VFS: Cannot open root device "mmcblk0p2" # 如果卡在这里 → rootfs挂载失败 # 检查：rootfs分区是否完整？root=参数是否正确？ [ 3.456] Kernel panic - not syncing: VFS: Unable to mount root fs # 内核panic，系统停止

6.2 U-Boot命令行排查

# 进入U-Boot命令行（启动时按任意键）=>printenv# 查看环境变量=>bootcmd# 查看启动命令=>mmc dev0# 切换到SD卡=>mmc info# 查看SD卡信息=>load mmc0:1 0x80080000 kernel.img# 手动加载内核=>bootm 0x80080000# 手动启动内核

6.3 常见不启动原因

现象	原因	解决方案
串口无任何输出	电源/Bootloader损坏	检查电源，重新烧录Bootloader
U-Boot卡死	DDR不稳定	检查DDR配置，降频测试
Kernel panic	rootfs找不到/损坏	检查root=参数，修复rootfs
启动循环重启	看门狗超时/内核崩溃	关闭看门狗测试，分析panic日志
停在Starting kernel	DTB不匹配/内核配置错误	确认DTB与硬件版本一致

七、故障6：看门狗误触发重启

设备运行正常但周期性重启，日志中无明显错误——可能是看门狗误触发。

7.1 确认是否看门狗复位

# 查看重启原因cat/proc/sys/kernel/random/boot_id# 每次启动不同lastreboot# 查看重启历史# 查看复位原因（不同平台命令不同）# 瑞芯微平台：cat/sys/kernel/debug/rk3x-wdt/reboot_reason# 或io-40xfdd09040# 读取复位原因寄存器# 内核日志dmesg|grep-i"watchdog\|reboot\|reset"# [ 10.234] rk3568-wdt: watchdog timeout, system reset

7.2 排查喂狗线程阻塞

# 用strace跟踪喂狗进程strace-p$(pidof watchdog_feeder)-T-tt# 如果看到某个系统调用阻塞时间很长，就是问题所在# 用perf分析喂狗线程的调度延迟perf sched record-p$(pidof watchdog_feeder)--sleep30perf sched latency

7.3 解决方案

# 1. 增大超时时间（临时缓解）# 修改喂狗程序中的超时设置# 2. 确保喂狗线程不被阻塞# - 喂狗线程不获取任何锁# - 不调用可能阻塞的IO函数# - 使用SCHED_FIFO实时调度策略# 3. 设置喂狗线程为实时优先级chrt-f-p80$(pidof watchdog_feeder)# -f: SCHED_FIFO, 80: 优先级# 4. 检查系统负载是否过高top-b-n1|head-20# 如果load average很高，可能CPU被占满，喂狗线程得不到调度

八、常用排查命令速查表

命令	用途	关键参数
`dmesg`	内核日志	`-T`显示时间戳,`--level=err`只看错误
`top`	进程CPU/内存	`-d 5`刷新间隔,`-H`显示线程
`iostat`	磁盘IO统计	`-x`详细统计,`-d 5`间隔
`vmstat`	虚拟内存统计	`vmstat 5`每5秒一次
`netstat`/`ss`	网络连接	`-tlnp`监听端口,`-tnp`活动连接
`strace`	系统调用跟踪	`-p PID`跟踪进程,`-T`显示耗时
`lsof`	打开的文件	`-p PID`指定进程
`tcpdump`	网络抓包	`-i eth0`指定网卡,`port 8080`过滤端口
`ethtool`	网卡状态	`eth0`查看链路状态
`smartctl`	磁盘健康	`-a /dev/sda`查看SMART信息
`journalctl`	systemd日志	`-u myapp`指定服务,`--since today`
`free`	内存使用	`-h`人类可读
`df`	磁盘空间	`-h`人类可读,`-i`inode使用

九、预防性运维建议

1. 日志先行

所有关键操作必须有日志记录，包括：启动/退出、异常恢复、看门狗喂狗、网络重连。出问题时日志是你唯一的线索。

2. 心跳上报

# 定期上报设备状态到服务器# /opt/scripts/heartbeat.sh#!/bin/bashSTATUS_URL="https://server.example.com/api/heartbeat"DEV_ID=$(cat/etc/device_id|cut-d=-f2)UPTIME=$(cat/proc/uptime|awk'{print $1}')MEM_FREE=$(free-m|awk'/Mem:/{print $4}')DISK_FREE=$(df-h/|awk'NR==2{print $5}')curl-s-XPOST"$STATUS_URL"-d"id=${DEV_ID}&uptime=${UPTIME}&mem=${MEM_FREE}&disk=${DISK_FREE}"

3. 自动恢复机制

看门狗：系统级保底，死机自动复位
systemd Restart=always：进程崩溃自动重启
网络自动重连：NetworkManager或自定义重连脚本
磁盘自动清理：超过阈值自动清理旧日志

4. 固件版本可追溯

每台设备的固件版本、硬件版本、部署日期都必须可查。出问题时第一件事是确认版本，避免在旧版本上排查已修复的bug。

# 一键导出设备诊断信息#!/bin/bash# /opt/scripts/diag.shecho"=== Device Info ==="cat/etc/versioncat/etc/device_idecho"=== Uptime ==="uptimeecho"=== Memory ==="free-hecho"=== Disk ==="df-hecho"=== Network ==="ipaddr showecho"=== dmesg (last 50) ==="dmesg|tail-50echo"=== Top Processes ==="top-b-n1|head-20echo"=== Recent Reboots ==="lastreboot|head-5