On Thu, 05.12.13 17:26, Canek Peláez Valdés ([email protected]) wrote: > Hi; I've been playing with systemd-nspawn with Gentoo. I'm running > systemd 208, and the normal Gentoo stage3 image [1], installing > systemd 204 inside it. Everything works great, but for some reason > after powering off the container, the file system where it resides > gets remounted read-only. I should notice that this is a file system > different from /.
Hmm, so, older versions of systemd did this as part of their shutdown logic. When shutting down a normal host we try to umount all file systems we can, and the ones we can't we try to remount read-only to ensure the file systems are in a clean state when the power is removed. In containers this unfortunately has the effect that the filesystem the host sees might too be remounted read-only. Thus, in a version long ago we added a crude check that skips the read-only mounting if we detect we are run in a container. I wonder if this might be broken for you? It would be good to strace the container's PID 1 when you shutdown (which you can nicely do from outside the container), and have a look at what it precisely does from the moment in where the /usr/lib/systemd/systemd-shutdown is invoked as PID 1. COuld you generate that and paste it somewhere plz? > Also, I usually need to machinectl terminate the machine, otherwise I > cannot start the same container with the same name (I think this is a > known bug). Yeah, this is fixed in newer systemd versions. It should suffice either upgrading the host or the guest to make this work, but in the best case update both. THis is caused by a stupid kernel interface that won't tell us that a cgroup ran empty as long as there are still subgroups around even if those are empty too... The newer versions of systemd will hence trim the cgroup tree right before invoking reboot(), and the newer versions of systemd-nspawn will explicitly remove the scope (and hence cgroup) when shutting down the container instead of relying on automatic clean-up. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
