Some of the checks were previously performed when parsing the network config.
But since we allow for a little more flexibility now it doesn't work anymore.
Instead, let's validate the network at creation time.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
lxc_get_netdev_by_idx() takes care of checking whether a given netdev struct
for a given index is already allocated. If so it returns a pointer to it to the
caller.
If it doesn't find it it will allocate a new netdev struct and insert it into
the network list at the right position. For example, let's say you have the
following networks defined in your config file:
lxc.network.0.type=veth
lxc.network.0.link=lxcbr0
lxc.network.0.name=eth0
lxc.network.0.flags=up
lxc.network.3.type=veth
lxc.network.3.link=lxcbr0
lxc.network.3.name=eth1
lxc.network.3.flags=up
lxc.network.3.hwaddr = 00:16:3e:5d:7d:65
lxc.network.1.type=veth
lxc.network.1.link=lxcbr0
lxc.network.1.name=eth0
lxc.network.1.flags=up
lxc_get_netdev_by_idx() will take care that the internal network list appears
in the order:
0
1
3
The ordering of the keys themselves can also be random, meaning you could do:
lxc.network.3.type=veth
lxc.network.0.link=lxcbr0
lxc.network.0.name=eth0
lxc.network.3.hwaddr = 00:16:3e:5d:7d:65
lxc.network.0.flags=up
lxc.network.3.flags=up
lxc.network.0.type=veth
lxc.network.3.link=lxcbr0
lxc.network.3.name=eth1
and lxc_get_netdev_by_idx() would still figure out the correct ordering since
it keeps track of the index.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When we merged the new logging function for the api we exposed the log level
argument in the struct as "priority" which we actually requested to be changed
to "level" which somehow didn't happen and we missed it. Given the fact there
has been no new liblxc release let's fix it right now before it hits users.
Also, take the chance to change the terminology in the log from "priority" to
"level" globally. This is to prevent confusion with syslog's "priority"
argument which we also support.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Since we kicked lxc-monitord there will very likely be no user processes around
anymore after all container's have been stopped. Which is a very very very good
thing. So let's not error out when pkill doesn't find any processes.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
A LXC container's lifecycle is regulated by the states STARTING, RUNNING,
STOPPING, STOPPED, ABORTING. These states are tracked in the LXC handler and
can be checked via approriate functions in the command socket callback system.
(The freezer stages are not part of a container's lifecycle since they are not
recorded in the LXC handler. This might change in the future but given that the
freezer controller will be removed from future cgroup implementations it is
unlikely.) So far, LXC was using an external helper to track the states of a
container (lxc-monitord). This solution was error prone. For example, the
external state server would hang in various scenarios that seemed to be caused
by either very subtle internal races or irritation of the external state server
by signals.
LXC will switch from an external state monitor (lxc-monitord) which serves as a
state server for state clients to a native implementation using the indiviual
container's command socket. This solution was discussed and outlined by Stéphane
Graber and Christian Brauner during a LX{C,D} sprint.
The LXC handler will gain an additional field to track state clients. In order
for a state client to receive state notifications from the command server he
will need to register himself via the lxc_cmd_state_server() function in the
state client list. The state client list will be served by lxc_set_state()
during the container's lifecycle. lxc_set_state() will also take care of
removing any clients from the state list in the LXC handler once the requested
state has been reached and sent to the client.
In order to prevent races between adding and serving new state clients the state
client list and the state field in the LXC handler will be protected by a lock.
This commit effectively deprecates lxc-monitord. Instead of serving states to
state clients via the lxc-monitord fifo and socket we will now send the state
of the container via the container's command socket.
lxc-monitord is still useable and will - for the sake of the lxc-monitor
command - be kept around so that non-API state clients can still monitor the
container during it's lifecycle.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Starting at version 3.6, Alpine Linux has support for ppc64le
architecture. Adding the new keys also.
Signed-off-by: Breno Leitao <breno.leitao@gmail.com>
The removed codepath was non-functional for a long time now. All mounting is
handled through bdev.{c,h} and if that fails the other codepath would
necessarily fail as well. So let's remove them. This makes it way clearer what
is going on and simplifies things massively.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
- Enable lxc_abstract_unix_{send,recv}_fd() to send and receive multiple fds at
once.
- lxc_abstract_unix_{send,recv}_fd() -> lxc_abstract_unix_{send,recv}_fds()
- Send tty fds from child to parent all at once.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This is a potentially security sensitive operation and I really want to keep an
eye on *when exactly* this is send. So add more logging on the TRACE() level.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This also fixes a bug where we caused a double mapping, when the {u,g}id for
the user was mapped to container root {g,u}id.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
