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

[John]

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.

[...]


>> 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.
> -serge
>