Commit 7df119ee by Daniel Lezcano Committed by Daniel Lezcano

unmount failure is not fatal

There are several cases where the system can no longer access a mount point or a mount point configuration makes the algorithm bogus. For example, we mount something and then we chroot, the mount information will give an unaccessible path and the container won't be able to start because this mount point will be unaccessible. But if it's the case, then we can just warn and continue running the container. Another case is the path to a mount point is not accessible because there is another mount point on top of it hiding the mount point. So the umount will fail and the container won't start. Easy to reproduce: mkdir -p /tmp/dir1/dir2 mount -t tmpfs tmpfs /tmp/dir1/dir2 mount -t tmpfs tmpfs /tmp/dir1 So can we just ignore the error when unmounting and continue to the list again and again until it shrinks. At the end, we just display the list of the unmounted points. Signed-off-by: 's avatarDaniel Lezcano <dlezcano@fr.ibm.com>
parent bd288c26
......@@ -538,19 +538,14 @@ static int setup_rootfs_pivot_root(const char *rootfs, const char *pivotdir)
continue;
}
if (errno != EBUSY) {
SYSERROR("failed to umount '%s'", (char *)iterator->elem);
return -1;
}
still_mounted++;
}
} while (still_mounted > 0 && still_mounted != last_still_mounted);
if (still_mounted) {
ERROR("could not umount %d mounts", still_mounted);
return -1;
}
lxc_list_for_each(iterator, &mountlist)
WARN("failed to unmount '%s'", (char *)iterator->elem);
/* umount old root fs */
if (umount(pivotdir)) {
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment