[lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
Michael H. Warfield
mhw at WittsEnd.com
Thu Oct 2 01:05:59 UTC 2014
On Wed, 2014-10-01 at 14:18 -0400, Stéphane Graber wrote:
> On Wed, Oct 01, 2014 at 12:41:26PM -0400, Michael H. Warfield wrote:
> > 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.
> There would be a list of variables which LXC exposes to the config
> parser, so LXC would still do the init system detection as it does
> today, though possibly add detection for a few more init systems and
> then set init_system accordingly before passing it to the parser. Same
> goes for runtime_mode, LXC would set this to "unprivileged" or
> "privileged" based on the usual userns check we have internally.
Sounds like a plan to me.
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!
> >
>
>
>
> > _______________________________________________
> > 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/fb3eb663/attachment.sig>
More information about the lxc-devel
mailing list