[lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
Michael H. Warfield
mhw at WittsEnd.com
Wed Oct 1 16:41:26 UTC 2014
On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
> On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
> > On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
> >
> > [snip]
> >
> > > > Would this be better if this paralleled autodev an we only disabled kmsg
> > > > by default if and when systemd was detected as the init system? The
> > > > situation is very analogous to the autodev situation. If a user were to
> > > > switch from say upstart to systemd and autodev is not specified in the
> > > > config, we default that to enabled when we detect systemd as the init
> > > > system at run time. We could also default kmsg to 0 in the case of
> > > > systemd being the run time init system manager to prevent journald from
> > > > going into it's console message loop and burning CPU. Would that work
> > > > better for you? Since you can switch init systems from within the
> > > > container and may not have access to the container config file that's in
> > > > the host, something should be done to cover the run time case, like we
> > > > do with autodev. That's what I was attempting to do...
> >
> > > I'm not very much fond of having to do per-init system config changes
> > > but yeah, that sounds like a reasonable way to go.
> >
> > > If we start getting more and more of those cases we may want to make
> > > things slightly more configurable by just having LXC include some
> > > default configuration files based on that detection.
> >
> > Oh? Sort of like conditional includes? If lxc.init = systemd include
> > systemd.conf sort of thing? It would have to be runtime conditional but
> > that does make some sense at that.
> So I see a few ways of doing it:
> 0) We keep all the logic hardcoded as it is today for autodev.
> 1) We keep your detection code and simply call
> load_config("/usr/share/lxc/config/<init-system>.conf") before parsing
> anything else, so the container's own config will override anything
> that's in there.
> 2) We make our parser support conditionals and export init_system as a
> variable so that we can have the default distro configs do things like:
> [init_system==systemd] lxc.include = /usr/share/lxc/config/systemd.common.conf
> [privileged==false] lxc.include = /usr/share/lxc/config/unpriv.common.conf
> This would be more flexible and allow for the addition of extra
> variables later on. It'd also allow switching between privileged and
> unprivileged and between init systems without configuration changes.
> 3) We do a slightly simpler version of the above by adding two things:
> - Simple variables, like ${init_system} and ${runtime_mode} and
> allow using them in the config with the parser replacing them with the
> right thing at parsing time.
> - Add a @ keyword which when placed at the beginning of the line
> will tell the parser to ignore any failure caused by the line in
> question.
> This then allows us to put things like:
> @lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
> @lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
> And not have the parser fail if I somehow decide to run OpenRC as my
> container's init system without an existing ubuntu.openrc.conf.
Ok... Option 0 is just about recoded so that the default kmsg is
dependent on systemd and not merely autodev. I've turned
"check_autodev" into "check_systemd" and conditionalized both autodev
and kmsg based on that return value, dependent on any explicitly set
value. For the short term, that appears to be the quickest and easiest.
Option 3 sounds like a good versatile long term option but we still need
some runtime autodetection of some of those values. Where does that
${init_system} come from? Since container owners can internally change
their run-time configuration to switch init system manager and then
reboot the container, something needs to be detected at runtime or the
container could end up being configured in ways that degrade the
performance or behavior of the host. Even then, we still might have a
gap in the reboot process if the configuration is not reevaluated when
the container is rebooted (aot shut down and restarted).
Not sure if I care that much for option #1. #2 would be my second
choice for a long term strategy with the proviso that we have some sort
of runtime detection.
Regards,
Mike
> > > > This bug is now closed, after I explained to the originator what the
> > > > problem was, but it points out the problem we're seeing from having kmsg
> > > > being a symlink to console and having journald run crazy in the
> > > > container...
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1141456
> > > >
> > > > --
> > > >
> > > > > (1) Starting a basic LXC container, which is not configured to do anything at all, *immediately* (and without delay) raises the temperature *substantially* of one of the cores.
> > > > >
> > > > > (2) Starting a second LXC container (also not configured to do anything), does the same as (1), but on a different core (i.e. the one that that LXC uses).
> > > > --
> > > >
> >
> > [Big snip - this time I remembered...]
> >
> > Regards,
> > Mike
> > --
> > Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
> > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
> >
>
>
>
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
>
>
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141001/9a253372/attachment.sig>
More information about the lxc-devel
mailing list