On Fri, Aug 23, 2019 at 08:23:06PM -0000, Tobias Koch wrote: > I may be missing the point, but the symlink in question is eventually > recreated, does that tell us anything? This here
Yes, this is more supporting evidence that this is a race condition; the state of the system both before and some time after the resize is consistent, the kernel/udev just lose track of the existence of the partition for some amount of time after the resize happens. > > Dan had put a udevadm settle in this spot like so > > > > def get_size(filename) > > util.subp(['udevadm', 'settle']) > > os.open(....) > > looks to me like the event queue should be empty now, but how do you > know userspace has acted on what came out of it? The symlink exists before the resize, so if it's missing then we know that the udev events have been processed. The DEVLINKS line in the diff in comment #24 shows that udev doesn't think that symlink should exist. We can see the symlink being deleted in the logging in comment #22. > Is it strictly required that any event is cleared only after the > corresponding action has completed? If yes, we can probably blame > udev. If not, cloud-init should wait on the link to appear. The link is not going to appear without something prompting a re-read of the partition table from udev. I don't believe this should be necessary if the kernel/udev are behaving properly. (Odds are that whatever causes it to be recreated later in boot would be blocked by cloud-init waiting.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
