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 | m...@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@lists.linuxcontainers.org > > > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > > > > > > > > _______________________________________________ > > > lxc-devel mailing list > > > lxc-devel@lists.linuxcontainers.org > > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > > > -- > > Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@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@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > > _______________________________________________ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@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!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel