[lxc-devel] [PATCH] have systemd service call lxc-autostart via script
Michael H. Warfield
mhw at WittsEnd.com
Thu May 1 22:31:42 UTC 2014
On Thu, 2014-05-01 at 17:57 -0400, Stéphane Graber wrote:
> On Thu, May 01, 2014 at 05:51:15PM -0400, Michael H. Warfield wrote:
> > On Thu, 2014-05-01 at 17:31 -0400, Stéphane Graber wrote:
> > > On Thu, May 01, 2014 at 05:14:12PM -0400, Michael H. Warfield wrote:
> > > > Related to this... Dwight and I have been bouncing a couple of things
> > > > back and forth and I noticed that lxc-autostart is being called from the
> > > > sysvinit scripts without the -a parameter. That means that any
> > > > container in a non-null group will not be autostart on boot. I feel
> > > > that's the wrong behavior. If autoboot = 1 then it should be autobooted
> > > > on boot. What you do after boot is up to you but I would expect it to
> > > > be "autoboot = 1" => "autobooted on bootup", not "autoboot = 1" =>
> > > > "autobooted on bootup if it's not in a group".
> >
> > > I can see why you'd auto-start both the null group and say a "boot"
> > > group, but I don't think we should auto-start them all.
> >
> > OTOH, I wanted to group my services "WittsEnd", "WittsEnd-DNS",
> > "WittsEnd-Web", "WittsEnd-DB" so they could be filtered and managed as
> > groups but I want them all to start at boot, maybe by groups (boot the
> > DNS first and then the DB and then the Web). I would control if they
> > autoboot at boot time with the autoboot parameter. The order grouping
> > can be handled now with some of the other options but, if autoboot does
> > not mean we autoboot the container then we chose the wrong name for the
> > parameter.
> >
> > Perhaps we need a parameter in /etc/lxc/lxc.conf that can specify what
> > groups to boot at boot time? The fact that this is not parameterized,
> > it works in a way that forces me to modify the system scripts with is
> > (cough) suboptimal. Alternatively, if a container could belong to
> > multiple groups, say "WittsEnd-DB,boot" then anything belonging to the
> > boot group would autoboot at boot (I'm sounding like I have a stutter
> > now) would then autoboot.
> >
> > > A reason is that I use those groups as a way to easily start a group of
> > > interdependent containers, when I need those, I do "lxc-autostart -g
> > > blah" and all containers that have lxc.group = blah and lxc.start.auto =
> > > 1 will start properly sorted, with the right delays, ...). I however
> > > don't necessarily want those to start at boot.
> >
> > That's fine for you but it's not how I need them to work in a production
> > environment when I reboot the iron. What you do after the iron is up is
> > not an "autoboot" condition but one where you are boot and controlling
> > groups. A friend of mine has "ByTheSea" and my son has "Malamaber" on
> > my colo iron. Using groups is great for me to shut down all the
> > "Malamber" containers collectively but I want all of them coming up if I
> > flip the BRS (Big Red Switch) on the iron.
> >
> > I've suggested two options above that could accommodate both paradigms.
> > Parameter in /etc/lxc/lxc.conf or multiple group memberships. Thoughts?
>
> Multiple group memberships is already supported, lxc.group is stored as
> a list so you could do as I suggested in my previous e-mail and have the
> init script call ("lxc-autostart && lxc-autostart -g boot") then have
> the containers you want to start at boot time have the lxc.group = boot
> on top of any existing lxc.group they may already have.
> Support for a list of groups to auto-start in /etc/lxc/lxc.conf was also
> part of the original specification, however this hasn't been implemented
> yet, mostly because the parser for lxc.conf is rather minimal and it
> seemed to much of a pain at the time :)
Well, wait a minute. Maybe it is and maybe it isn't. What if that
parameter was a direct analog of the -g parameter? IOW, you don't allow
multiple instantiations but just have a single parameter with a comma
separated list just like you have with -g? That seems pretty simple.
Just malloc a string and store it. You've already go the run-time
parser chopping up that csv string from the -g parameter (which would
obviously override).
> Regardless, patches are welcome for that bit :)
I may look at this.
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140501/09ca7951/attachment.sig>
More information about the lxc-devel
mailing list