[lxc-devel] [PATCH] have systemd service call lxc-autostart via script

Thu May 1 22:25:47 UTC 2014

On Thu, 2014-05-01 at 18:17 -0400, Stéphane Graber wrote:
> On Thu, May 01, 2014 at 06:07:21PM -0400, Michael H. Warfield wrote:
> > 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.
> > 
> > Ok...  I didn't realize that.  Good to know.  Can we also specify a list
> > of groups to boot with lxc-autostart that includes the null group?  If
> > so, I might suggest a patch that would boot <NULL> and "boot".
> > Alternative there would be to run lxc-autostart twice.  Once for <NULL>
> > and once for "-g boot".  That would be a workaround for my case.

> Or we could support the rather weird "-g ,boot" which would stand for
> "those that have lxc.group empty and those that have boot in lxc.group".
> I don't think this works at the moment but could certainly be made to
> work fairly easily.

Our minds are on the same track and it's not so weird and it certainly
has precedence on varying levels.  The one that immediately pops to mind
(and screams caution) is the notation in rsync involving leading and
trailing slashes and how they're interpreted.  This is simple in
comparison.

> > Funny.  With multiple group membership and the use of a boot group, that
> > almost makes the autoboot parameter redundant.  :-P  Or, maybe, closer
> > to the openvz "disabled" parameter.  I'll have to think on that a bit.
> > 
> > > 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 :)
> > 
> > Yeah I know.  I've got battle scars from working on parsers too.  Here
> > there be dragons.
> > 
> > > Regardless, patches are welcome for that bit :)

[Big Snip]

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/ccfbd15f/attachment.sig>