Hm.

udevd applies MTU property from the link file in the link_config_apply()
function, which is called by builtin_net_setup_link(), from the
net_setup_link builtin.

Reading the conditions for builtin_net_setup_link_init() and
builtin_set_setup_link_validate(), the link configuration context is
never recreated; but paths_check_timestamp(link_dirs,
&ctx->link_dirs_ts_usec, false) is used to determine if things need to
be reloaded. It verifies the time of last modification (st_mtim) on the
directories that hold the link files.

However, udevd only calls validate on the builtins at most every 3
seconds (see udevd.c). Thus if one changes link files (e.g. modification
time on the directory less than 3 seconds since the last udev scan), and
one triggers to run 80-net-setup-link, the link files will not be re-
read and nothing new will happen.

>From the original logs, it seems like everything happens within the same
second on boot. Hence the race.

It would be interesting to boot the bad instances with udev debugging
enabled, to observe the messages related to realoding net link
configuration and/or applying it, e.g. the interesting messages are:

Created link configuration context.
Unloaded link configuration context.
Check if link configuration needs reloading.

Udev debugging can be set by changing /etc/udev/udev.conf and use
udev_log="debug", or by booting with udev.log-priority=debug on the
kernel command line.

Also it would be interesting to see, if we can sleep for 3 seconds,
before triggering udevadm add.

I understand that hardcoding 3 second sleep is sub-optimal, this is
purely to establish if the above analysis is a complete red-herring or
not =)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1669564

Title:
  udevadm trigger subsystem-match=net doesn't always run rules

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to