On Fri, 2013-10-04 at 11:56 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > My second takeaway from the Linux Plumbers conference was to do an > > automatic heuristic determination when we should enable autodev > > (mounting of something on /dev/ in the container at startup for things > > like systemd). If autodev is not enabled when it is required (systemd) > > the container can cause the host to hang or behave indeterminently due > > to devtmpfs being mounted in both the host and the container.
> I don't understand... shouldn't it suffice for the fedora (and other > systemd-based) template to always set autodev to 1? For modern supported versions of Fedora, yes. However... The real world scenario is one of an older Fedora (14 or earlier) being upgraded through "yum distrosync" up to a newer Fedora (17 or higher) by the owner of the container (I do this all the time). The what was a non-systemd container becomes a systemd container and a reboot then has some serious negative consequence for the host system itself. The container owner may not have the ability to update (or even know to update) the autodev option in the older config file. I can see this as a potentially valid scenario with other distros as well. > Leaving the decision entirely up to the template also should simplify > doing the /dev/$container/ bind-mount into $container/dev like you > were wanting to do. The template can "just do it" without having to > worry about being second-guessed by lxc itself. I agree with that. > There are plenty of ways for a wrong or malicious template to hose > the system - this is just one more. Hardcoding a "fix" for this in > lxc itself will, I fear, only make things more complicated if/when > there is a change to devtmpfs behavior, i.e. if it were to start > supporting newinstance mounts. Honestly, once I get some more testing done on this devtmpfs stuff, I can see a day coming when autodev becomes the default whether we are using systemd or not, or maybe the default if the host has devtmpfs mounted on its /dev. I've been playing with some of that already, where I can move things (devices) in and out of a container dynamically from the host. Some of my testing has to also include seeing the impact of setting autodev on containers that don't run systemd. I ran into some problems way back when we initially set up autodev when I tried that. I got strange permissions on devices in those containers that were not running autodev and never did sort out why. Once I have that done, I'll probably post the preliminary /dev bind mount patches. Probably later this week. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | 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
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
