On Tue, May 2, 2017 at 8:54 AM, Dimitri John Ledkov <[email protected]> wrote:
> Ideally, the following should happen: > * boot > * Created link configuration context > <netplan creates/changes .link files to have a new MTU setting> > * Check if link configuration needs reloading -> appears in the debug logs > * New MTU is successfully applied > Let me put in the cloud-init sequence and see if we can figure out what may be missing. * boot * systemd-udev* sockets, trigger, settle, udevd , cloud-init-local : run * cloud-init writes a netplan.yaml * cloud-init invokes netplan-generate * system reaches sysinit.target Looking at the deps on the systemd-udev units; there's no strict ordering in cloud-init that says it would run before, or strictly after udev related units. If you note about the ignoring updated files that are less than 3 seconds old as well as systemd's variability w.r.t unit ordering due to missing explicit Before/After directives might explain the race. I'd prefer not to wait for 3 seconds just because; so it maybe use useful to see if we can run cloud-init before udev; however it's not clear if invoking udev settle in cloudinit (which is done at various places directly (or indirectly through calling programs like blkid or other system programs) would end up waiting. We could also explicitly order cloud-init-local after the udevd service which depends on all other udev units; however, if cloud-init runs immediately after it, the 3 seconds may not have passed. I like running after udevd, but I would like to see if we can force/configure udev to not wait that 3 seconds; > If the 'Check ...' is missing from the debug logs, after netplan has > run, udevd will not reload the configs. > > I also would have thought that calling udevadm control --reload would > force it to reload the contexts for the builtins. > > >From the original bug report description there is a call to: > 'systemctl', 'start', '--no-block', 'systemd-udev-trigger.service' > > But if one is doing that, to avoid races, one should call udevadm settle > -t 3 before re-triggering add. > Note that -t 3, --timeout=3 only sets the maxium wait time; this means that if it processes any event with in those 3 seconds, that we may not have waited long enough for udev when it re-reads link files and says it's not 3 seconds since the last time. The 3 second re-read is arbitrary and ideally should be replaced by content hashing or use of inotify such that changes to the file (.link) can be triggered automatically without hacky things like sleep 3. > These things are possibly red herrings too. > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 > -- 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
