如何防止udevd错误地排队删除设备ppp事件？

Question

使用SynCE将PDA设备与Debian连接起来，识别USB串行设备，并与ttyUSB总线连接，获得IP地址，并在几秒钟(2，最多3)后断开连接。这就是它在syslog中的样子：

Jan 18 20:26:57 debian10 dccm[1505]: Message: synce_device_dbus_init: registering object path '/org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0'
Jan 18 20:26:57 debian10 dccm[1505]: DEBUG: synce_device_manager_device_obj_path_changed_cb: sending connected signal for /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0
Jan 18 20:26:57 debian10 dccm[1505]: DEBUG: synce_device_dbus_init: obj_path set to /org/synce/dccm/Device/_devices_pci0000_00_0000_00_06_0_usb2_2_2_2_2_1_0_ttyUSB0_tty_ttyUSB0
Jan 18 20:26:57 debian10 dccm[1505]: DEBUG: get_password_flag_text: setting password flags unset
Jan 18 20:26:57 debian10 dccm[1505]: DEBUG: synce_device_legacy_info_received: setting CTRL_STATE_CONNECTED
Jan 18 20:26:58 debian10 dccm[1505]: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/tx-0
Jan 18 20:26:58 debian10 dccm[1505]: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0/queues/rx-0
Jan 18 20:26:58 debian10 dccm[1505]: DEBUG: gudev_uevent_callback: received uevent **remove** for device /sys/devices/virtual/net/ppp0

看到输出，我决定深入研究使用"udevadm控件-l调试“监视UDEV事件.结果是：

Jan 23 15:01:28 debian10 dccm[1157]: DEBUG: get_password_flag_text: setting password flags unset
Jan 23 15:01:30 debian10 systemd-udevd[237]: Cleanup idle workers
Jan 23 15:01:30 debian10 systemd-udevd[1322]: Unload module index
Jan 23 15:01:30 debian10 systemd-udevd[1322]: Unloaded link configuration context.
Jan 23 15:01:30 debian10 systemd-udevd[1299]: Unload module index
Jan 23 15:01:30 debian10 systemd-udevd[1299]: Unloaded link configuration context.
Jan 23 15:01:30 debian10 systemd-udevd[237]: Worker [1299] exited
Jan 23 15:01:30 debian10 systemd-udevd[237]: Worker [1322] exited
Jan 23 15:01:30 debian10 systemd-udevd[237]: rx-0: Device (SEQNUM=1738, ACTION=remove) is queued
Jan 23 15:01:30 debian10 systemd-udevd[237]: Validate module index
Jan 23 15:01:30 debian10 systemd-udevd[237]: Check if link configuration needs reloading.
Jan 23 15:01:30 debian10 systemd-udevd[237]: Successfully forked off 'n/a' as PID 1327.
Jan 23 15:01:30 debian10 systemd-udevd[237]: rx-0: Worker [1327] is forked for processing SEQNUM=1738.
Jan 23 15:01:30 debian10 systemd-udevd[237]: tx-0: Device (SEQNUM=1739, ACTION=remove) is queued
Jan 23 15:01:30 debian10 systemd-udevd[237]: Successfully forked off 'n/a' as PID 1328.
Jan 23 15:01:30 debian10 systemd-udevd[237]: tx-0: Worker [1328] is forked for processing SEQNUM=1739.
Jan 23 15:01:30 debian10 systemd-udevd[237]: ppp0: Device (SEQNUM=1740, ACTION=remove) is queued
Jan 23 15:01:30 debian10 systemd-udevd[1327]: rx-0: Processing device (SEQNUM=1738, ACTION=remove)
Jan 23 15:01:30 debian10 systemd-udevd[1328]: tx-0: Processing device (SEQNUM=1739, ACTION=remove)
Jan 23 15:01:30 debian10 dccm[1157]: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0/queues/tx-0
Jan 23 15:01:30 debian10 systemd-udevd[1328]: tx-0: Device (SEQNUM=1739, ACTION=remove) processed
Jan 23 15:01:30 debian10 dccm[1157]: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0/queues/rx-0
Jan 23 15:01:30 debian10 systemd-udevd[1327]: rx-0: Device (SEQNUM=1738, ACTION=remove) processed
Jan 23 15:01:30 debian10 systemd-udevd[1327]: rx-0: sd-device-monitor: Passed 157 byte to netlink monitor
Jan 23 15:01:30 debian10 systemd-udevd[1328]: tx-0: sd-device-monitor: Passed 157 byte to netlink monitor
Jan 23 15:01:30 debian10 systemd-udevd[237]: ppp0: sd-device-monitor: Passed 179 byte to netlink monitor
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: Processing device (SEQNUM=1740, ACTION=remove)
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: RUN 'ifupdown-hotplug' /usr/lib/udev/rules.d/80-ifupdown.rules:5
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: IMPORT builtin 'path_id' /usr/lib/udev/rules.d/80-net-setup-link.rules:5
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: IMPORT builtin 'path_id' fails: No such file or directory
Jan 23 15:01:30 debian10 systemd-udevd[1327]: Starting 'ifupdown-hotplug'
Jan 23 15:01:30 debian10 systemd-udevd[1327]: Successfully forked off '(spawn)' as PID 1329.
Jan 23 15:01:30 debian10 systemd-udevd[1327]: Process 'ifupdown-hotplug' succeeded.
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: Device (SEQNUM=1740, ACTION=remove) processed
Jan 23 15:01:30 debian10 dccm[1157]: DEBUG: gudev_uevent_callback: received uevent remove for device /sys/devices/virtual/net/ppp0
Jan 23 15:01:30 debian10 systemd-udevd[1327]: ppp0: sd-device-monitor: Passed 298 byte to netlink monitor
Jan 23 15:01:34 debian10 systemd-udevd[237]: Cleanup idle workers
Jan 23 15:01:34 debian10 systemd-udevd[1327]: Unload module index
Jan 23 15:01:34 debian10 systemd-udevd[1327]: Unloaded link configuration context.
Jan 23 15:01:34 debian10 systemd-udevd[1328]: Unload module index
Jan 23 15:01:34 debian10 systemd-udevd[1328]: Unloaded link configuration context.
Jan 23 15:01:34 debian10 systemd-udevd[237]: Worker [1327] exited
Jan 23 15:01:34 debian10 systemd-udevd[237]: Worker [1328] exited

显然，SynCE使用基于glib的gudev来监视udev事件。侦听事件"uevent“信号，若要这样做，请将回调附加到此信号并等待通知。USB设备没有拔出插头，没有理由发出信号“动作删除”。在Ubuntu14.04中，它的工作原理非常好。

我的知识来了。我不知道如何接近问题的根源。我需要使连接ppp0 <-> /dev/ttyUSB0 0稳定。任何帮助或建议都会受到很好的欢迎和极大的感谢。

Answer 1

如何防止udevd错误地排队删除设备ppp事件？

udevd没有做任何“错误”的事情；ACTION=remove是由内核发出的(并由udevd重新发出)，因为设备已经消失了，而不是相反。换句话说，udevd只是对移除作出反应，而不是造成它。

USB设备没有拔出插头，没有理由发出信号“动作删除”。

日志中的事件与ttyUSB0设备无关--它们只提到ppp0网络接口，这是完全不同的事情。ttyUSB0设备并不是ppp0存在的原因--创建ppp0的是pppd守护进程。

(因此“/sys/设备/虚拟”。直接连接到某个物理设备的网络接口实际上会显示为该物理设备的子设备。)

由于ppp0是由pppd动态创建的，因此最有可能导致它消失的原因是pppd进程因某种原因崩溃或退出。

(不过，它不一定非得是pppd - dccm本身可能处理PPP并创建这个接口--但这有点不太可能；大多数这样的工具并不试图重新发明东西，它们只是生成pppd。)

Answer 2

udev手册给了我一个答复：

不允许启动守护进程或其他长时间运行的进程；分离或不分离的分叉进程将在事件处理完成后无条件地终止。为了从udev规则中激活长时间运行的进程，提供一个服务单元并使用SYSTEMD_WANTS设备属性从udev设备中提取它。

更新的udev版本(来自Ubuntu 16和Debian 8)通过对udev事务和由udev生成的进程有严格的时间限制，使您无法在运行或程序脚本中启动长期存在的后台进程。至于对udev派生脚本的长时间运行的进程限制，如果您在后台启动一些东西，只要udev启动的实际脚本很快终止。Udev使用cgroup寻找n个销毁生成的任务。因此，所有线程都接收终止信号。

systemd路由是正确的方法，因为不建议从udev开始长期运行的进程。