Howto prevent udevd wrongly enqueues remove event for device ppp?

Connecting a PDA device with Debian using SynCE, USB serial device is recognized and connects with ttyUSB bus, obtains an IP address and disconnects after a few seconds (two, max three). This is how it looks in 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

Seeing the output, I decided to delve deeper into monitoring UDEV events with "udevadm control -l debug"... and this was the result:

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

Evident, SynCE use glib based gudev to monitor the udev events. Listen to the events "uevent" signal, to do that, attach a callback to this signal and wait for the notification. The USB device is not unplugged, no reason for signal "action remove". With Ubuntu 14.04 it works out of the box very well.

Here comes my knowledge. I don't know how to get closer to the origin of the problem. I need to make the connection ppp0 <--> /dev/ttyUSB0 stable. Any help or suggestion will be well received and greatly appreciated.

Howto prevent udevd wrongly enqueues remove event for device ppp?

udevd isn't doing anything "wrongly"; ACTION=remove is emitted by the kernel (and re-emitted by udevd) because the device has disappeared – not the other way around. In other words, udevd is only reacting to the removal, not causing it.

The USB device is not unplugged, no reason for signal "action remove".

The events in your log have nothing to do with the ttyUSB0 device – they only mention the ppp0 network interface, which is a completely different thing. The ttyUSB0 device is not what makes ppp0 exist – it's the pppd daemon that creates ppp0.

(Hence "/sys/devices/virtual". A network interface that was directly attached to some physical device would actually show up as a child of that physical device.)

Because ppp0 is created dynamically by pppd, the most likely cause for it disappearing is the pppd process crashing or exiting for some reason.

(Though, it doesn't necessarily have to be pppd – it is possible that dccm itself handles PPP and creates this interface – but that's somewhat less likely; most such tools don't try to reinvent things, they just spawn pppd.)

The udev manual give me the response:

Starting daemons or other long-running processes is not allowed; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using the SYSTEMD_WANTS device property.

Newer udev versions (from Ubuntu 16 and Debian 8) prevents you from starting long-lived background processes in RUN or PROGRAM scripts by having a strict time limit for udev transactions and processes spawned by them. As for the long-running process restriction on udev-spawned scripts, if you start something in the background, as long as the actual script udev launches terminates quickly. Udev uses cgroups to seek-n-destroy spawned tasks. Consequently, all the threads receive the signal to terminate.

The systemd route is the right way, since starting long-running processes from udev is not recommended.