@edolstra @dezgeg

Looks good.

FWIW the original problem is probably related to udev having the block device open for probing filesystems on it (like described at https://groups.google.com/forum/#!topic/scylladb-dev/u87yHgo3ylU).

@dezgeg so is not killing udev likely to bite us in other subtle ways later? It definitely seemed to be hurting our NVMe discovery on EC2, but it's unclear to me how to make sure the other issue doesn't pop up again. We already ask it to settle at various points along the way.

Yeah, probably the settles that are added are now enough.

Does this need a backport to 18.03 as well?

Looks good to me.

I would hold off on backporting to 18.03 until we feel confident that the race with udev that prompted the addition of the udevadm control --exit is really gone.

I would think the udev blkid race could be avoided by wrapping certain parts in udevadm control --stop-exec-queue and udevadm control --start-exec-queue as was proposed in the scylladb thread (and in fact would be the only way to fix the similar races that sometimes happen in NixOS installer tests).

For reference (to confirm that I am not talking crazy stuff :), these are the occasional failures I see in the installer tests which I believe to be related to the udev race: https://nix-cache.s3.amazonaws.com/log/rwfcwv4p18sbbnd7pna2r2m9aqz7s2m5-vm-test-run-installer-luksroot.drv

machine: must succeed: parted --script /dev/vda -- mkpart primary linux-swap 50M 1024M
machine# [   35.973121] systemd[1]: Started Networking Setup.
machine# [   35.978131] systemd[1]: Starting Extra networking commands....
machine# [   36.549789]  vda: vda1 vda2
machine# Error: Partition(s) 2 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.