summaryrefslogtreecommitdiff
path: root/src/core/dbus-execute.c
diff options
context:
space:
mode:
authorHarald Hoyer <harald@redhat.com>2015-11-24 09:41:26 +0100
committerHarald Hoyer <harald@redhat.com>2015-11-24 14:08:50 +0100
commit9d06297e262966de71095debd1537fc223f940a3 (patch)
tree9f70586f2c2a8b849df7e80441bdc63483442654 /src/core/dbus-execute.c
parente35a7876b4ab1d53a7539a905613e31dc6ae50fd (diff)
core: Do not bind a mount unit to a device, if it was from mountinfo
If a mount unit is bound to a device, systemd tries to umount the mount point, if it thinks the device has gone away. Due to the uevent queue and inotify of /proc/self/mountinfo being two different sources, systemd can never get the ordering reliably correct. It can happen, that in the uevent queue ADD,REMOVE,ADD is queued and an inotify of mountinfo (or libmount event) happend with the device in question. systemd cannot know, at which point of time the mount happend in the ADD,REMOVE,ADD sequence. The real ordering might have been ADD,REMOVE,ADD,mount and systemd might think ADD,mount,REMOVE,ADD and would umount the mountpoint. A test script which triggered this behaviour is: rm -f test-efi-disk.img dd if=/dev/null of=test-efi-disk.img bs=1M seek=512 count=1 parted --script test-efi-disk.img \ "mklabel gpt" \ "mkpart ESP fat32 1MiB 511MiB" \ "set 1 boot on" LOOP=$(losetup --show -f -P test-efi-disk.img) udevadm settle mkfs.vfat -F32 ${LOOP}p1 mkdir -p mnt mount ${LOOP}p1 mnt ... <dostuffwith mnt> Without the "udevadm settle" systemd unmounted mnt while the script was operating on mnt. Of course the question is, why there was a REMOVE in the first place, but this is not part of this patch.
Diffstat (limited to 'src/core/dbus-execute.c')
0 files changed, 0 insertions, 0 deletions