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: Daniel Lezcano <dlezcano@fr.ibm.com>

diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 1a9f5df61fccd0c12c771638196a15d5931b684f..eef67f1071c26157c4dc06dbd26f4015333b8d9f 100644 (file)
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -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)) {