[Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

[Serge Hallyn]

Quoting John (lxc at jelmail.com):
> On 07/12/12 13:50, Serge Hallyn wrote:
> > Quoting John (lxc at jelmail.com):
> >> On 07/12/12 00:48, Serge Hallyn wrote:
> >>> Quoting John (lxc at jelmail.com):
> >>>> On 06/12/12 20:06, Dan Kegel wrote:
> >>>>> On Thu, Dec 6, 2012 at 12:00 PM, John <lxc at jelmail.com> wrote:
> >>>>>> While on the subject, any reason for lxc-destroy now being destructive?
> >>>>> Wait, isn't that the point?  It's in the name and all.
> >>>>>
> >>>>> When was it ever nondestructive?
> >>>>>
> >>>> It only destroyed the configuration in /var/lib and never deleted the
> >>>> root filesystem until very recently (0.8.0, I guess).
> >>> Was your rootfs a symbolic link by chance?  I'm guessing commit
> >>> 55116c42e767ce795f796fc51cd2ef7d76cf18af is what you're seeing.  Before
> >>> that it did remove the rootfs, but if your rootfs was a symlink it
> >>> happened to not do it.  That wasn't by intent.
> >>>
> >>> Perhaps lxc-destroy should take a flag to not delete the rootfs?  Not
> >>> sure...
> >>>
> >> Ah, I can now see what is wrong. It isn't down to symlinks but
> >> beacuase my rootfs isn't under /var/lib/lxc.
> >>
> >> Looking at that commit, I can see that the remove (on line 126)
> >> deletes "$lxc_path/$lxc_name" but does not explictly remove
> >> "$rootdev". The new code added at line 122 does indeed remove
> >> $rootdev.
> >>
> >> In my case I have my container rootfs in a directory called
> >> "/srv/test.i686" (i.e not underneath $lxc_path - /var/lib/lxc). I
> >> guess the design assumes that a template is used to create a
> >> container and that it would put the rootfs beneath /var/lib/test.
> >>
> >> So the commit fixes an anomaly but leaves me unsure of a couple of things:
> >>
> >> 1. what is the correct way to update a container config without
> >> removing the rootfs. I have always used destroy/create to do this
> >> but that, clearly, won't work if the destroy phase removes the
> >> rootfs. I like being able to separately manage the rootfs from its
> >> configuration.
> > This I don't really understand - I've always done it by hand.  What
> > exactly is made easier by doing destroy/create?  Maybe we can reproduce
> > that with an lxc-update or something...  Especially if we can then
> > have lxc-update expand variables and take a list of containers to
> > update to batch the operations.  Though still right now I would just
> > default to a bash loop calling sed...
> 
> I always treated /var/lib/lxc as "internal". From the early days, 
> /etc/lxc was suggested as a configuration directory and where the 
> original configuration would lie. Using lxc-create copied that config 
> into /var/lxc. This, in my mind, meant that I shouldn't mess with the 
> config inside /var/lib/lxc but should instead modify /etc/lxc and then 
> do a destroy/create. I may have been living on a mis-premise all this 
> time but that's how I've been using it.

No actually I like that.  I've not done it, but it seems sound.

> >> I would value having options to preserve the rootfs when doing
> >> lxc-destroy and for lxc-create to use an existing rootfs (i.e.
> >> instead of a template).
> > Ok, I don't *really* want to make lxc-destroy not delete the rootfs
> > just if it is outside of /var/lib/lxc/$container...  On the one hand
> > I can see people could do that specifically in the hopes of making
> > it outlive the container.  On the other hand I could see people doing
> > it only because they are short on disk space ending up running out of
> > disk space because they lost track of where the undeleted rootfs's
> > were.
> >
> > Maybe
> >
> > 	lxc-destroy -k -n p1
> >
> > for "--keep" (don't delete the rootfs)?
> yes, that would work.

Great - if someone gets to writing that patch before I do, +1.

-serge