On Sat, 07.12.13 19:03, Colin Guthrie ([email protected]) wrote: > > 'Twas brillig, and Shawn Landden at 07/12/13 18:57 did gyre and gimble: > > On Sat, Dec 7, 2013 at 10:33 AM, Colin Guthrie <[email protected]> wrote: > >> Hi, > >> > >> When playing with systemd-nspawn, is there a way to override the kernel > >> command line seen inside the container. I mean it's probably not correct > >> that the host systems /proc/cmdline leaks into the container. > > > No it is not, /proc/cmdline cannot be changed. What is your use case? > > Perhaps this could be added to UTS namespaces? > > Could you not bind mount over it with a temporary file? Might be kinda > tricky to do tho' if it is possible. > > My main use case is that we have a rescue system which passes "rescue" > on the command line of the host system. > > If I use this system to "boot" containers (which would typically be the > system we are "rescuing", then it reads this "rescue" is read in the > container and starts rescue.target automatically rather than whatever > default.target is. We'd probably want to specifically boot a > multi-user.target by default and the best way to do that temporarily > would be to provide a fake "command line" to the booted instance. > > Now we could change what we use to identify our rescue image, but it > would seem to me that this shouldn't be needed and faking kernel command > lines as seen by containers should be something that's possible.
So, we don't really have a clear story here. As Shawn pointed out we can certainly overmount /proc/cmdline, but you currently have to request that manually. We actually already overmount /proc/sys/kernel/random/boot_id so that every boot-up in the container gets its own boot ID, which makes the journal a lot nicer to work with (because otherwise journalctl -b is not so fun to use...) Now, if we play this game for the boot id I does make we wonder why we shouldn't also play the same game for /proc/cmdline. I mean, in general I think the onus should be on the container manager to virtualize things properly. Working around container limitations from the inside sounds much less ideal. So yeah, maybe we should generate a throw-away temporary file where we write all addition arguments of the nspawn command line into and then mount that into /proc/cmdline. Then, lets drop the special container checking in systemd for accessing /proc/cmdline. And also update the container interface wiki doc, so that other container managers follow suit. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
