[Debian] Re: Bug#527986: #527986 Follow-up

[Ola Lundqvist]

Hi Orion

I have now found the problem. I have also found a number of other potential
problems with this mounting scheme. I think I have solved most of them but do not know
that for sure.

I have uploaded a fixed version to unstable. Please test it.

There are complications with this setup, but this one will at least allow
to remove it even though there are some issues left.

Best regards,

// Ola

On Sat, May 23, 2009 at 04:31:54PM +0200, Ola Lundqvist wrote:
> Hi Orion
> 
> On Fri, May 22, 2009 at 07:15:55PM +0100, Orion wrote:
> > 
> > I have exactly the same problem as the original poster on the newest
> > stable version of OpenVZ.
> > 
> > # vzctl destroy 139
> > Destroying VE private area: /var/lib/vz/private/139
> > Can't create tmp dir /var/lib/vz/private/13/vztmp: No such file or
> > directory
> > 
> > It seems that the last digit of the three numbers is strangely missing
> > from the tmp dir error. The original poster has the same problem too. I
> > also have a comparable filesystem arrangement due to needing to
> > span across two disks. I have ext3 on /, /var/lib/vz,
> > and /var/lib/vz/private/139. Destroying the 139 node causes the
> > problem shown above. However, destroying any other node works perfectly.
> > So the problem is clearly related to using two or more filesystems for
> > VZ containers.
> 
> Thanks a lot. I'll try to reproduce the problem with a similar setup. I do not
> think it is the filesystem that is the problem, but rather the fact that
> the filesystem is mounted as it is.
> 
> > The output of /var/lib/vz and /var/lib/vz/private shows entirely the
> > same information for each directory, essentially a mask of 755
> > (read-write-execute for the owner, and read-execute for the rest) with
> > root ownership. It doesn't as far as I can see appear to be a
> > permissions problem.
> > 
> > A workaround to solve the problem of removing a container is to
> > clear all relevant files from the individual private filesystem (i.e
> > private/139) and then unmount it. After that, you can call the normal
> > destroy command to get rid of all other related files. This works
> > perfectly. 
> 
> Thanks for the information.
> 
> Best regards,
> 
> // Ola
> 
> > Orion
> > 
> > 
> > 
> 
> -- 
>  --------------------- Ola Lundqvist ---------------------------
> /  opal at debian.org                     Annebergsslingan 37      \
> |  ola at inguza.com                      654 65 KARLSTAD          |
> |  http://inguza.com/                  +46 (0)70-332 1551       |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---------------------------------------------------------------
> 

-- 
 --- Inguza Technology AB --- MSc in Information Technology ----
/  ola at inguza.com                    Annebergsslingan 37        \
|  opal at debian.org                   654 65 KARLSTAD            |
|  http://inguza.com/                Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------