[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