Well, not all of my hard disc, just /lib and /usr/lib, and not all of those either because I got suspicious and stopped it before it finished. But the damage was severe enough to require an OS reinstall.
This was with lxc 0.8.0 on x86 Linux (the relevant 0.9.0 code looks substantially similar). It happened shortly after installing lxc for the first time to try it out. I believe what must have happened was that the container I created wasn't shut down properly and still had its bind mounts for /lib etc. in place. The container must have been down enough to be considered not running according to lxc-info, so lxc-destroy helpfully rm -rf'ed it, including the contents of the bind mounts which pointed into my host system. rm was given the --one-file-system option, but it didn't prevent this from occurring, presumably because the device ID of the container location was the same as the device ID of the /lib of the host. After looking at the source to lxc-destroy, I'm surprised this kind of problem doesn't happen more often--it is not at all defensively written (error codes ignored, arguments not properly quoted, this problem I'm writing about, etc.), so I was glad to see that lxc-destroy has since been reimplemented. However, on briefly looking at the new source, it seems that the same problem can still occur. There's a comparison of device IDs before deleting files (presumably, to try to accomplish the same thing as rm's --one-file-system option), but my situation of bind mounts on the same filesystem device means once again that wouldn't be effective in preventing this erroneous deletion. I strongly suggest improving the checks before deletion to avoid this kind of problem in the future. This may be as simple as checking the bind mount points against /proc/mounts before starting the destroy process. >>> Dan _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
