It is impolite to print stuff to stderror owned by other people, and they might
miss it anyway since it's not in the normal log location.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Instead, the parent always writes a status to the pipe.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Previously, lxcapi_restore used the calling process as the lxc monitor process
(and just never returned), requiring users to fork before calling it. This, of
course, would cause problems for things like LXD, which can't fork.
Now, restore() forks the monitor as a child of the process that calls it. Users
who want to daemonize the restore process need to fork themselves.
lxc-checkpoint has been updated to reflect this behavior change.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
CRIU needs to be told when something is bind mounted into the container from
the outside as cgmanager's socket is.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
The logging code uses a global log_fd and log_level to direct
logging (ERROR(), etc). While the container configuration file allows
for lxc.loglevel and lxc.logfile, those are only used at configuration
file read time to set the global variables. This works ok in the
lxc front-end programs, but becomes a problem with threaded API users.
The simplest solution would be to not allow per-container configuration
files, but it'd be nice to avoid that.
Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible",
but would be a huge complication as there are many functions, including
struct member functions and callbacks, which don't have that info and
would need to get it from somewhere.
So the approach I'm taking here is to say that all real container work
is done inside api calls, and therefore the API calls themselves can
set a thread-local variable indicating which log info to use. If
unset, then use the global values. The lxc-* programs, when called
with a '-o logfile' argument, set a global variable to indicate that
the user-specified value should be used.
In this patch:
If the lxc container configuration specifies a loglevel/logfile, only
set the lxc_config's logfd and loglevel according to those, not the
global values.
Each API call is wrapped to set/unset the current_config. (The few
exceptions are calls which do not result in any log actions)
Update logfile appender to use the logfile specified in lxc_conf if (a)
current_config is set and (b) the lxc-* command did not override it.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Following the model of f0f1d8c076, add a reboot
signal for special init processes that work on something other than SIGINT.
Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Instead of having a parent process that's called whatever the caller of the
library is called, we instead set it to "[lxc monitor] <lxcpath> <container>"
Closes#180
v2: check for null in tok for loop, only truncate environment when necessary
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
The `index` libc function was removed in POSIX 2008, and `strchr` is a direct
replacement. The bionic (Android) libc has removed `index` when you are
compiling for a 64-bit architecture, such as AArch64.
Signed-off-by: Patrick O'Leary <patrick.oleary@gmail.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The following functions return immediately if a null pointer was passed.
* container_destroy
* lxc_cgroup_process_info_free_and_remove
* lxc_cgroup_put_meta
* toss_list
It is therefore not needed that a function caller repeats a corresponding check.
This issue was fixed by using the software Coccinelle 1.0.0-rc23.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The function "free" is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
This issue was fixed by using the software Coccinelle 1.0.0-rc23.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
We want to close all inherited fds in three cases - one, if a container
is daemonized. Two, if the user specifies -C on the lxc-start command
line. Three, in src/lxc/monitor.c. The presence of -C is passed in the
lxc_conf may not always exist.
One call to lxc_check_inherited was being done from lxc_start(), which
doesn't know whether we are daemonized. Move that call to its caller,
lxcapi_start(), which does know.
Pass an explicit closeall boolean as second argument to lxc_check_inherited.
If it is true, then all fds are closed. If it is false, then we check
the lxc_conf->close_all_fds.
With this, all tests pass, and the logic appears correct.
Note that when -C is not true, then we only warn about inherited fds,
but we do not abort the container start. This appears to have ben the case
since commit 92c7f62955 in 2011. Unfortunately the referenced URL with
the justification is no longer valid. We may want to consider becoming
stricter about this again. (Note that the commit did say "for now")
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This isn't the perfect fix. In fact close_all_fds shouldn't be stored
in the lxc_conf. But this will fix the tests short-term.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
When containers request to be daemonized, close-all-fd is
set to true. But when we switched ot daemonize-by-default we didn't
set close-all-fd by default.
Fix that. In order to do that we have to always have a lxc_conf
object. As a consequence, after this patch we can drop a bunch
of checks for c->lxc_conf existing. We should consider removing
those. This patch does not do that.
This should close https://github.com/lxc/lxc/issues/354
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
On restore, we pass criu a script to manage the network interfaces (i.e. the
full path to lxc-restore-net), which we previously installed into
/var/lib/<tuple>/lxc. However, this is also the directory that is the default
for use in mounting the rootfs locally before pivot_root()ing. So, we mounted
the rootfs and then happliy called criu, pointing it to this directory which
didn't have lxc-restore-net any more, it just had the container's rootfs.
Instead, we should put lxc-restore-net somewhere else, so that criu can still
see it after the rootfs is mounted.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
We previously wrote a bunch of files (eth*, veth*, and bridge*) as hard coded
files which we used as the names of interfaces to restore via criu's
--veth-pair. This meant that if people, e.g. gave a different bridge on their
new host, we would use our saved bridge in bridge* and try to restore to the
wrong bridge. Instead, we can just generate a new veth id (if the user hasn't
provided one), and use whatever the user configured values for the interface
name and bridge are.
This allows people to switch the bridge that they restore onto simply by
migrating the rootfs and config, and then changing the bridge name in the
container's configuration before running lxc-checkpoint.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Break the monolithic ->checkpoint and ->restore functions into smaller ones.
This is in preparation for the checkpoint/restore tty work, which has a similar
need to dump information outside of criu.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
The python lxc-device supported adding wlan devices, so add that
support as well. Since the python one did not support 'del',
I didn't try adding that support, though it should be trivial to
add.
We should be able to do the wlan adding using netlink, but I
went ahead and used 'iw' as the netlink path looked more
complicated than it does for other nics. Patches to switch that
over would be very welcome.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Currently, we depends on ip command to attach interface to container.
It means we only implemented it by python.
This patch implement adding and removing interface by c and added
them in struct container.
Changelog: 10/15/2014 (serge): return error if ifname is NULL.
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Function of enter_to_ns() is useful but currently is static for
lxccontainer.c.
This patch split it into two parts named as switch_to_newuser()
and switch_to_newnet() into utils.c.
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Previously, we let criu create the cgroups for a container as it was restoring
things. In some cases (i.e. migration across hosts), if the container being
migrated was in /lxc/u1-3, it would be migrated to the target host in
/lxc/u1-3, even if there was no /lxc/u1-2 (or worse, if there was already an
alive container in u1-3).
Instead, we use lxc's cgroup_create, and then tell criu where to restore to.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
On Tue, Oct 07, 2014 at 07:33:07PM +0000, Tycho Andersen wrote:
> This commit is in preparation for the cgroups create work, since we will need
> the handler in both the parent and the child. This commit also re-works how
> errors are propagated to be less verbose.
Here is an updated version:
From 941623498a49551411ccf185146061f3f37d3a67 Mon Sep 17 00:00:00 2001
From: Tycho Andersen <tycho.andersen@canonical.com>
Date: Tue, 7 Oct 2014 19:13:51 +0000
Subject: [PATCH 1/2] restore: Hoist handler to function level
This commit is in preparation for the cgroups create work, since we will need
the handler in both the parent and the child. This commit also re-works how
errors are propagated to be less verbose.
v2: rename error to has_error, handle it correctly, and remove some diff noise
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This is in preparation for the cgroups creation work, but also probably just a
good idea in general. The ERROR message is handy since we print line nos. it
will to give people an indication of what arg was null.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
With cgmanager, the cgroups are polled on demand, so these steps aren't needed.
However, with cgfs, lxc doesn't know about the cgroups for a container and so
it can't report any of the statistics about e.g. how much memory or CPU a
container is using.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
The ->checkpoint() API call didn't exit correctly if criu was killed by a
signal instead of exiting, so lxc-checkpoint didn't fail correctly as a result.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
After looking through some logs, it is a little cleaner to do it as
below, instead of what I originally posted.
Tycho
In order for LXC to be the parent of the restored process, CRIU needs to
restore init as its sibling, not as its child. This was previously accomplished
essentially via luck :). CRIU now has a --restore-sibling option which forces
this behavior that LXC expects. See more discussion in this thread:
http://lists.openvz.org/pipermail/criu/2014-September/thread.html#16330
v2: don't pass --restore-sibling to dump. This is mostly cosmetic, but will
look less confusing in the logs if people ever look at them.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
We can also narrow the scope of this, since we only need it in the process that
is actually going to use it.
Reported-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
If we just return here, we end up with two processes executing the caller's
code, which is not good.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This option is required when migrating containers across hosts; it is used to
restore inotify via file paths instead of file handles, which aren't preserved
across hosts.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
And add a testcase.
The code to update hwaddrs in a clone was walking through the container
configuration and re-printing all network entries. However network
entries from an include file which should not be printed out were being
added to the unexpanded config. With this patch, at clone we simply
update the hwaddr in-place in the unexpanded configuration file, making
sure to make the same update to the expanded network configuration.
The code to update out lxc.hook statements had the same problem.
We also update it in-place in the unexpanded configuration, though
we mirror the logic we use when updating the expanded configuration.
(Perhaps that should be changed, to simplify future updates)
This code isn't particularly easy to review, so testcases are added
to make sure that (1) extra lxc.network entries are not added (or
removed), even if they are present in an included file, (2) lxc.hook
entries are not added, (3) hwaddr entries are updated, and (4)
the lxc.hook entries are properly updated (only when they should be).
Reported-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
With the new hashed command socket names (e85898415c), it's possible to
have something like below;
[caglar@qop:~/go/src/github.com/lxc/go-lxc(master)] cat /proc/net/unix | grep lxc
0000000000000000: 00000002 00000000 00010000 0001 01 53465 @lxc/d086e835c86f4b8d/command
[...]
list_active_containers reads /proc/net/unix to find all running
containers but this new format no longer includes the container name or
its lxcpath.
This patch introduces two new commands (LXC_CMD_GET_NAME and
LXC_CMD_GET_LXCPATH) and starts to use those in list_active_containers
call.
changes since v1:
- added sanity check proposed by Serge
Signed-off-by: S.Çağlar Onur <caglar@10ur.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This patch adds support for checkpointing and restoring containers via CRIU.
It adds two api calls, ->checkpoint and ->restore, which are wrappers around
the CRIU CLI. CRIU has an RPC API, but reasons for preferring exec() are
discussed in [1].
To checkpoint, users specify a directory to dump the container metadata (CRIU
dump files, plus some additional information about veth pairs and which
bridges they are attached to) into this directory. On restore, this
information is read out of the directory, a CRIU command line is constructed,
and CRIU is exec()d. CRIU uses the lxc-restore-net callback (which in turn
inspects the image directory with the NIC data) to properly restore the
network.
This will only work with the current git master of CRIU; anything as of
a152c843 should work. There is a known bug where containers which have been
restored cannot be checkpointed [2].
[1]: http://lists.openvz.org/pipermail/criu/2014-July/015117.html
[2]: http://lists.openvz.org/pipermail/criu/2014-August/015876.html
v2: fixed some problems with the s/int/bool return code form api function
v3: added a testcase, fixed up the man page synopsis
v4: fix a small typo in lxc-test-checkpoint-restore
v5: remove a reference to the old CRIU_PATH, and a bad error about the same
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This prevents u2 from going into /home/u1/.local/share/lxc/u1/rootfs
and running setuid-root applications to get write access to u1's
container rootfs.
v2: set umask to 002 for the mkdir. Otherwise if umask happens to be,
say, 022, then user does not have write permissions under the container
dir and creation of $containerdir/partial file will fail.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
When we read a lxc.network.hwaddr line, if it contained any 'x's then
those get quitely filled in at config_network_hwaddr. If that happens
then we want to save the autogenerated hwaddr in the unexpanded config
so that when we write it to disk, it is saved.
This patch dumbly re-generates the network configuration in the
unexp configuration every time we load a config file, just as we do
after every clone.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This commit broke the testsuite for unprivileged containers as the
container directory is now 0750 with the owner being the container root
and the group being the user's group, meaning that the parent user can
only enter the directory, not create entries in there.
This reverts commit c86da6a3ac.
This prevents u2 from going into /home/u1/.local/share/lxc/u1/rootfs
and running setuid-root applications to get write access to u1's
container rootfs.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Dwight Engen <dwight.engen@oracle.com>
Actually, get rid of the temporary variables, and set newname
and lxcpath to usable values if they were NULL.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Especially when using the Python API, the child process inherits of
the file descriptiors of the script.
Signed-off-by: Vincent Giersch <vincent.giersch@ovh.net>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
They don't work right now, so until we fix that, don't allow it.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Originally, we only kept a struct lxc_conf representing the current
container configuration. This was insufficient because lxc.include's
were expanded, so a clone or a snapshot would contain the expanded
include file contents, rather than the original "lxc.include". If
the host's include files are updated, clones and snapshots would not
inherit those updates.
To address this, we originally added a lxc_unexp_conf, which mirrored
the lxc_conf, except that lxc.include was not expanded.
This has its own cshortcomings, however, In particular, if a lxc.include
has a lxc.cgroup setting, and you use the api to say:
c.clear_config_item("lxc.cgroup")
this is not representable in the lxc_unexp_conf. (The original problem,
which was pointed out to me by stgraber, was slightly different, but
unlike this problem it was not unsolvable).
This patch changes the unexpanded configuration to be a textual
representation of the configuration. This allows us *order* the
configuration commands, which is what was not possible using the
struct lxc_conf *lxc_unexp_conf.
The write_config() now becomes a simple fwrite. However, lxc_clone
is slightly complicated in parts, the worst of which is the need to
rewrite the network configuration if we are changing the macaddrs.
With this patch, lxc-clone and clear_config_item do the right thing.
lxc-test-saveconfig and lxc-test-clonetest both pass.
There is room for improvement - multiple calls to
c.append_config_item("lxc.network.link", "lxcbr0")
will result in multiple such lines in the configuration file. In that
particular case it is harmless. There may be cases where it is not.
Overall, this should be a huge improvement in terms of correctness.
Changelog: Aug 1: updated to current lxc git head. All lxc-test* and
python api test passed.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This gives me:
ubuntu@c-t1:~$ lxc-create -t download -n u1
lxc_container: No mapping for container root
lxc_container: Error chowning /home/ubuntu/.local/share/lxc/u1/rootfs to container root
lxc_container: You must either run as root, or define uid mappings
lxc_container: To pass uid mappings to lxc-create, you could create
lxc_container: ~/.config/lxc/default.conf:
lxc_container: lxc.include = /etc/lxc/default.conf
lxc_container: lxc.id_map = u 0 100000 65536
lxc_container: lxc.id_map = g 0 100000 65536
lxc_container: Error creating backing store type (none) for u1
lxc_container: Error creating container u1
when I create a container without having an id mapping defined.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
