[systemd-devel] systemd-nspawn and kernel command line

Lennart Poettering lennart at poettering.net
Sun Dec 8 15:55:34 PST 2013


On Sat, 07.12.13 19:03, Colin Guthrie (gmane at colin.guthr.ie) 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 <gmane at colin.guthr.ie> 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


More information about the systemd-devel mailing list