Comment 19 for bug 1999178

With 'resolve_names=late' in udev configuration there is no change in behaviour. 'netplan generate' still takes about 1 min to complete.
Deleting the link from /usr/lib/systemd/system-generators 'fixes' the problem, but there are side effects, I guess.

On Thu, Jul 04, 2024 at 12:14:55PM -0000, Lukas Märdian wrote:
> I wonder if we could make use of the `resolve_names=late` setting from
> udev.conf(5), to work around this behavior?
>
> https://www.freedesktop.org/software/systemd/man/latest/udev.conf.html
>
> E.g. something like this:
>
> $ mkdir -p /etc/udev/udev.conf.d/
> $ echo "resolve_names=late" > /etc/udev/udev.conf.d/netplan.conf
> $ reboot
>
> Could anybody who's affected by this give this workaround a try?
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2069495).
> https://bugs.launchpad.net/bugs/1999178
>
> Title:
> netplan generator causes deadlock during systemd daemon-reload
>
> Status in Netplan:
> Triaged
>
> Bug description:
> From the issue in the systemd tracker [1]:
>
> During a systemd daemon-reload, the Netplan generator in
> /usr/lib/systemd/system-generators/netplan tries to reload the udev
> rules and databases with udevadm control --reload [2], which causes a
> deadlock, because reloading udev rules and databases requires a
> functioning systemd-userdbd.service, which is not the case during a
> systemd daemon-reload. The systemd developers will not consider making
> changes to any systemd component in order to prevent this deadlock,
> and instead suggest that the Netplan developers generate their systemd
> link/network/netdev units using a generator service like systemd-
> network-generator.service.
>
> [1] https://github.com/systemd/systemd/issues/25543
> [2] https://github.com/canonical/netplan/blob/bf8036d43837bc071d1d3f716f67dc24ef5a5b23/src/generate.c#L54
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1999178/+subscriptions
>