Comment 51 for bug 2009141

> > The very first one of those tracebacks happens on udev settle for the
> > network device (before any zfcp devices):
>
> Just re-iterating in case this is not related to block devices.

I appreciate the heads up, thanks! Indeed, we also call udevadm settle as the result of network events. On the other hand, all the tracebacks that I have seen so far in the logs shared seem to originate from the filesystem code, including this one:

> The very first one of those tracebacks happens on udev settle for the network device (before any zfcp devices):
>
> 2023-04-06 19:17:21,023 DEBUG subiquity.server.controllers.filesystem:671 waiting 0.1 to let udev event queue settle
> 2023-04-06 19:17:21,124 DEBUG subiquitycore.utils:64 run_command called: ['udevadm', 'settle', '-t', '0']
> 2023-04-06 19:17:21,139 DEBUG subiquitycore.utils:77 run_command ['udevadm', 'settle', '-t', '0'] exited with code 0
> 2023-04-06 19:17:21,139 ERROR subiquity.server.server:424 top level error
> Traceback (most recent call last):
> File "/snap/subiquity/4383/usr/lib/python3.8/asyncio/events.py", line 81, in _run
> self._context.run(self._callback, *self._args)
> File "/snap/subiquity/4383/lib/python3.8/site-packages/subiquity/server/controllers/filesystem.py", line 682, in _udev_event
> action, dev = self._monitor.receive_device()
> File "/snap/subiquity/4383/lib/python3.8/site-packages/pyudev/monitor.py", line 400, in receive_device

But I'm happy to be wrong. Have I overlooked something?

I've been able to reproduce the same stack by generating a burst of udev events using `udevadm trigger`.

Based on some reading, it seems that pyudev is mishandling the POLLIN + POLLERR combination; and fails to recover from it. There is an existing upstream discussion: https://github.com/pyudev/pyudev/issues/194

And a patch was merged in radvd for a similar situation: https://github.com/radvd-project/radvd/pull/160

Thanks,
Olivier