- So far we blindly called lxc_delete_network() to make sure that we deleted
  all network interfaces. This resulted in pointless netlink calls, especially
  when a container had multiple networks defined. Let's be smarter and have
  lxc_delete_network() return a boolean that indicates whether *all* configured
  networks have been deleted. If so, don't needlessly try to delete them again
  in start.c. This also decreases confusing error messages a user might see.

- When we receive -ENODEV from one of our lxc_netdev_delete_*() functions,
  let's assume that either the network device already got deleted or that it
  got moved to a different network namespace. Inform the user about this but do
  not report an error in this case.

- When we have explicitly deleted the host side of a veth pair let's
  immediately free(priv.veth_attr.pair) and NULL it, or
  memset(priv.veth_attr.pair, ...) the corresponding member so we don't
  needlessly try to destroy them again when we have to call
  lxc_delete_network() again in start.c
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

This allows to retrieve a file descriptor referring to a namespace.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

When we set LXC_DEBUG_CGFSNG=1 we print out info about detected cgroup
hierarchies. When there's no named cgroup mounted we need to make sure that we
don't try to index an unallocated pointer.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

With the criu release 2.8 criu deprecated the --veth-pair command-line
option in favor of --external:

f2037e6 veth: Make --external support --veth-pair

git tag --contains f2037e6d3445fc400
v2.8

With this commit lxc-checkpoint will automatically switch between
the new and old command-line option dependent on the detected
criu version.

For criu version older than 2.8 something like this will be used:

  --veth-pair eth0=vethYOK6RW@lxcbr0

and starting with criu version 2.8 it will look like this:

  --external veth[eth0]:vethCRPEYL@lxcbr0
Signed-off-by: Adrian Reber <areber@redhat.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

This package doesn't exist in stretch anymore, and it's unclear why we
were depending on a library to begin with (as opposed to having it
brought by whatever needs it).
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>

This is a GNU extension and some libcs might be missing it.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Evgeni Golov <evgeni@debian.org>

Signed-off-by: Evgeni Golov <evgeni@debian.org>

there is no reason to not do this :)
Signed-off-by: Evgeni Golov <evgeni@debian.org>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Add squashfs format file support for lxc-ubuntu-cloud.in
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>

Add zesty to KNOWN_RELEASES
Remove EOL wily from KNOWN_RELEASES
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>

In case the system was booted with

    isolcpus=n_i-n_j,n_k,n_m

we cannot simply copy the cpuset.cpus file from our parent cgroup. For example,
in the root cgroup cpuset.cpus will contain all of the cpus including the
isolated cpus. Copying the values of the root cgroup into a child cgroup will
lead to a wrong view in /proc/self/status: For the root cgroup
/sys/fs/cgroup/cpuset /proc/self/status will correctly show

    Cpus_allowed_list:      0-1,3

even though cpuset.cpus will show

    0-3

However, initializing a subcgroup in the cpuset controller by copying the
cpuset.cpus setting from the root cgroup will cause /proc/self/status to
incorrectly show

    Cpus_allowed_list:      0-3

Hence, we need to make sure to remove the isolated cpus from cpuset.cpus. Seth
has argued that this is not a kernel bug but by design. So let us be the smart
guys and fix this in liblxc.

The solution is straightforward: To avoid having to work with raw cpulist
strings we create cpumasks based on uint32_t bit arrays.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

lxc_append_string() appends strings without separator. This is mostly useful
for reading in whole files line-by-line.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

this patch create /var/run link to point to /run.

This will fix various issue present when /var/run is persistent.
Signed-off-by: Marc Gariepy <gariepy.marc@gmail.com>

If we do it earlier we end up with a wrong view of /proc/self/cgroup. For
example, assume we unshare(CLONE_NEWCGROUP) first, and then create the cgroup
for the container, say /sys/fs/cgroup/cpuset/lxc/c, then /proc/self/cgroup
would show us:

     8:cpuset:/lxc/c

whereas it should actually show

     8:cpuset:/
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

This would already fail, but with a not-as-good error message. Let's make
the error better.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

When we read sizeof(buf) bytes here, we'd write off the end of the array,
which is bad :)
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

The macros put a \n in for us, so let's not put another one in.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

This also allows us to commonize some bits of the dup2 code.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

On shutdown we move physical network interfaces back to the
host namespace and rename them afterwards as well as in the
later lxc_network_delete() step. However, if the device had
a name which already exists in the host namespace then the
moving fails and so do the subsequent rename attempts. When
the namespace ceases to exist the devices finally end up
in the host namespace named 'dev<ID>' by the kernel.

In order to avoid this, we do the moving and renaming in a
single step (lxc_netdev_move_by_*()'s move & rename happen
in a single netlink transaction).
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>

We need to log longer lines due to CRIU arguments.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

We switched to --ext-mount-map auto because of "system" (liblxc) added
mounts like the cgmanager socket that weren't in the config file. This had
the added advantage that we could drop all the mount processing code,
because we no longer needed an --ext-mount-map argument.

The problem here is that mounts can move between hosts. While
--ext-mount-map auto does its best to detect this situation, it explicitly
disallows moves that change the path name. In LXD, we bind mount
/var/lib/lxd/shmounts/$container to /dev/.lxd-mounts for each container,
and so when a container is renamed in a migration, the name changes.
--ext-mount-map auto won't detect this, and so the migration fails.

We *could* implement mount rewriting in CRIU, but my experience with cgroup
and apparmor rewriting is that this is painful and error prone. Instead, it
is much easier to go back to explicitly listing --ext-mount-map arguments
from the config file, and allow the source of the bind to change. We leave
--ext-mount-map auto to catch any stragling (or future) system added
mounts.

I believe this should fix Launchpad Bug 1580765
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

When the container is already running our manpage promises to exit with 2.
Let's make it so.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Somehow this implementation of a cgroupfs backend decided to use the hierarchy
numbers it detects in /proc/cgroups and /proc/self/cgroups as indices for
the hierarchy struct. Controller numbering usually starts at 1 but may start at
0 if:

    a) the controller is not mounted on a cgroups v1 hierarchy;
    b) the controller is bound to the cgroups v2 single unified hierarchy; or
    c) the controller is disabled

To avoid having to rework our fallback backend significantly, we should
explicitly check for each controller if hierarchy[i] != NULL.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

If cgroupv2 is enabled either alone or together with legacy hierarchies
/proc/self/cgroup can contain entries of the form:

        0::/

These entries need to be skipped.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

it's "list of columns", not "list of column"
Signed-off-by: Evgeni Golov <evgeni@debian.org>

Signed-off-by: Evgeni Golov <evgeni@debian.org>

this is how it is shipped in Debian and Ubuntu
Signed-off-by: Evgeni Golov <evgeni@debian.org>

And let's be on the safe side by NULLing free()ed variables.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>

Signed-off-by: Evgeni Golov <evgeni@debian.org>

Closes: #502
Signed-off-by: Evgeni Golov <evgeni@debian.org>