我之前处理过类似的Linux设备管理异常，这个问题的核心在于动态设备节点复用和hald事件触发的竞态条件，下面给你拆解原因和可行的解决方案：

问题根源分析 #

当你拔掉正在播放的USB摄像头后，系统会回收对应的/dev/input/event*节点，但如果紧接着插入键盘，这个节点会被快速复用给键盘。此时：

• 你的播放应用可能还持有旧设备的文件描述符或监听着旧节点的事件
• hald虽然会清理/dev条目，但它的事件触发逻辑依赖sysfs的设备状态，在节点被快速复用的场景下，会出现竞态——hald还没来得及发送旧设备的移除事件，新设备已经占用了该节点，导致事件丢失，最终键盘无法被正确识别。

具体解决方案 #

1. 放弃依赖动态/dev/input/event*节点，改用设备唯一标识 #

不要直接绑定/dev/input/eventX这种动态变化的节点，而是基于设备的唯一属性来关联：

• 用udevadm info --query=property --name=/dev/input/eventX获取设备的ID_SERIAL、ID_PATH等唯一标识
• 让应用通过udev（而非hald）监听设备的添加/移除事件，通过这些唯一标识来区分设备，即使节点被复用，也能准确识别新设备。

2. 修复hald的事件触发规则 #

如果必须继续使用hald，可以修改其配置强制发送USB输入设备的移除事件：

• 在/etc/hal/fdi/policy/目录下创建10-usb-input-remove.fdi文件，内容如下：

  <deviceinfo version="0.2">
    <device>
      <match key="info.category" string="input">
        <match key="info.parent.category" string="usb">
          <notify event="remove" />
        </match>
      </match>
    </device>
  </deviceinfo>
  

• 重启hald服务生效：

  sudo service hald restart
  

  这个规则会强制hald在USB输入设备移除时发送通知，减少竞态导致的事件丢失。

3. 应用层优化设备句柄管理 #

在播放摄像头的应用中增加容错逻辑：

• 定期检查持有的设备文件描述符是否有效（比如用fcntl(fd, F_GETFL)调用，失败则说明设备已移除）
• 一旦收到设备移除事件（不管来自hald还是udev），立即关闭对应的设备句柄，释放资源，避免占用节点导致新设备无法被识别。

4. 迁移到udev替代hald（推荐） #

hald已经被多数现代Linux发行版弃用，udev的设备事件管理更可靠：

• 在/etc/udev/rules.d/下创建99-usb-input-events.rules规则文件：

  # 监听USB输入设备移除事件
  ACTION=="remove", SUBSYSTEM=="input", ENV{ID_BUS}=="usb", RUN+="/usr/local/bin/handle_device_change.sh remove $devpath"
  # 监听USB输入设备添加事件
  ACTION=="add", SUBSYSTEM=="input", ENV{ID_BUS}=="usb", RUN+="/usr/local/bin/handle_device_change.sh add $devpath"
  

• 你的应用可以通过libudev库直接监听udev事件流，实时获取设备的添加/移除状态，完全规避节点复用带来的问题。

关于hald不发移除事件的疑惑 #

hald的设备跟踪依赖sysfs中的设备条目，当设备被快速移除并复用节点时，会出现竞态条件：hald还没检测到旧设备的sysfs条目被删除，新设备已经创建了相同的/dev节点，导致hald误以为旧设备仍然存在，从而跳过了移除事件的发送。这是hald设计上的局限性，也是推荐迁移到udev的原因之一。

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