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

Fri May 2 00:29:31 UTC 2014

On Thu, 2014-05-01 at 22:07 +0000, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > 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

> It seems to me cleaner to put a list of groups to auto-start at
> boot in /etc/default/lxc.  It's something for only the init script
> to care about, not lxc itself.

Possibly so, possibly no.  I'm ambivalent about that, over and above the
fact that it shoves it off onto distro dependent default locations and
formations.

It seems clear to me that we've got a problem with the unique nature of
the null group (i.e. when a group is not assigned to a group - I'll call
this group <NULL>).  Since multiple group membership is allowed, we need
to take in to consideration the nature of this <NULL> group.  If a
container is a member of ANY other group, it is automagically NOT a
member of the <NULL> group.  Therefore, by it's nature, the <NULL> group
can not be joined with other groups in a multigroup set, giving rise to
the boot logic problem here.

By defaulting the autoboot process to the <NULL> group, we exacerbate
the problem because any membership in any group automatically removes
you from the <NULL> group so you can't automatically boot at boot time
if you are a member of any group.  If we default the boot process to ANY
other group (boot, autoboot, etc) we avoid this problem because the
specific discreet group can then be joined to others.  That's very
significant difference.

Short term, I would propose, in the autoboot process, to first boot any
members of a specific and agreed upon group like boot or autoboot (my
personal preference) and then boot any members of the <NULL> group in
all cases predicated that lxc.boot.autoboot = 1.

In the case of the systemd service and sysvinit scripts that Dwight and
I have been hashing over, I would propose, as a short term "fix"
something like this in the lxc sysvinit script:

        # Start containers
        wait_for_bridge
+       # Start autoboot containers first.
+       action $"Starting LXC autoboot containers: " /usr/bin/lxc-autostart -g autoboot
+       # Start NULL group containers last.
        action $"Starting LXC containers: " /usr/bin/lxc-autostart

That should carry us over till we can get this parameterized at a deeper
level and does not conflict with any such parameterization.

What you do in Upstart is up to you.

The changes Dwight has submitted are complex enough in renames and files
that I'm not comfortable with submitting a patch until those are
incorporated.  If Dwight wants to update his patch, I would support
that.

As a side note...  We need to look forward to some utilities what would
add/set/delete/modify autoboot, delay, order and group options on
containers rather than forcing users to edit the individual config
files.  These would likely be trivial shell scripts but they still need
to be done.  Just rivets that need to be punched on the boiler.

> > 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 :)
> > 
> > Regardless, patches are welcome for that bit :)

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