为何执行dmesg | grep acm会出现多个ttyACM0实例？未连接串口设备的ttyACM2为何出现在列表中？

你的问题场景 #

你运行dmesg | grep acm后发现日志里重复出现ttyACM0，而且明明没接设备到ttyACM2，这个节点却也出现在列表里，结合你提供的日志，我来拆解下背后的原因：

你贴出的日志信息 #

[ 6.075663] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[ 6.088262] cdc_acm 3-4.1.3:1.0: ttyACM1: USB ACM device
[ 6.088935] usbcore: registered new interface driver cdc_acm
[ 6.088937] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 81.979767] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[ 117.307776] cdc_acm 3-4.1.1:1.0: ttyACM2: USB ACM device
[ 2126.911886] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[ 2139.455925] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[ 2227.775910] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[ 2265.151729] cdc_acm 3-4.1.1:1.0: ttyACM2: USB ACM device
[62661.970060] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[62674.513699] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[62847.569753] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device
[62888.785759] cdc_acm 3-4.1.1:1.0: ttyACM0: USB ACM device

为什么会有多个ttyACM0？ #

你注意看日志里的设备路径3-4.1.1:1.0，所有重复的ttyACM0都来自同一个USB端口的同一个设备接口，这不是新设备，而是同一个设备反复断开又重新连接了。常见诱因有这几个：

• USB连接不稳：线缆老化、接口松垮，或者用了供电不足的USB hub，导致设备时不时掉线再重连，每次重连驱动都会重新注册ttyACM0，所以日志里会反复出现这条记录。
• 设备自身复位：比如你用的是开发板、串口转USB模块这类设备，固件重启、内部电路复位都会导致USB连接重建，触发驱动重新识别。
• 系统的重连机制：如果系统检测到设备通信超时、异常，会尝试重新初始化设备，这也会生成这类重复日志。

没接设备，ttyACM2哪来的？ #

ttyACM2同样来自3-4.1.1:1.0，说明它还是那个老设备，只是重连时分配了新的设备编号，原因在于Linux的设备编号规则：

• Linux不会主动回收已分配的tty编号，除非你重启系统或者手动删除节点。当原来的ttyACM0因为设备断开被标记为未使用，但如果系统没及时清理，或者设备重连太快，内核可能会觉得ttyACM0还被占用（比如用户空间程序没释放），就会跳过它给新连接分配下一个可用编号，也就是ttyACM2。
• 还有一种情况是设备突然断开，内核没来得及正确释放ttyACM0的资源，导致下次重连时无法复用原编号，只能用新的。

排查和解决的小建议 #

1. 先排查硬件：换一根质量靠谱的USB线，直接插主机的原生USB口（别用hub），看看是不是还会频繁重连。
2. 检查设备节点状态：跑ls /dev/ttyACM*看看实际存在哪些节点，再用lsof /dev/ttyACM0查下有没有程序在占用这个节点，要是有，先关掉试试。
3. 手动清理残留节点：如果确定ttyACM2没有对应物理设备，用sudo rm /dev/ttyACM2删掉它，下次设备重连应该会复用空闲的编号。
4. 检查设备固件：如果是自己的开发板，排查下固件里有没有频繁复位的逻辑，这可能是根源。

内容的提问来源于stack exchange，提问作者Archie