A couple of comments on the suggested path:

> Imho the sequency of commands should be:
> * take flock on the device, to neutralise udev

+1  on this approach. Do you know if the flock will block
systemd's inotify write watch on the block device which triggers
udevd?  This is the typical race we see with partition creation
and rules executing.

> * modify device with sfdisk
> * reread partitions tables (i would say with blockdev --rereadpt, rather than 
> partx/partprobe)

I'm not sure we can use blockdev --rereadpt as we are operating upon the
root disk we're booted on and my understanding is that the ioctl that
partx uses is the only way to update the kernel partition table while
the disk is in use, otherwise we'd see the normal warning message like
when you fdisk your booted device and it says the disk is busy and
cannot read the partition table.

> * release the flock

+1

> * udevadm trigger --action=add --wait device (or trigger && settle)

I don't relish the idea of *re-adding* actions on the disk again since the 
partx update
should have already emitted the uevents associated with the new partitions.  
However,
we could do this as a way to force reloading of everything.  I'd like to 
withhold
judgement on whether we need this after testing with use of flock on the device.

> And like have a canary "only use locked codepath on this region" such
that we can assert through testing that this no longer happens with new
code, but does with old code.

The change to cloud-utils growpart could add a flag (--use-flock) so
cloud-init could emit different log messages on which path it takes
(including a warning if we cannot use flock (ie, you may race).

-- 
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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to