- 20 Jan, 2018 1 commit
-
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
- 19 Jan, 2018 39 commits
-
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Tycho Andersen authored
Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
Now that we have things propagated through init and liblxc correctly, at least in non-daemon mode, we can exit with the actual exit status of the task, instead of always succeeding, which is not so helpful. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
This seems slightly counter-intuitive, but IMO it's what we want. Basically, ->start() should succeed if the container is spawned correctly (similar to how golang's exec.Cmd.Start() returns nil if the thing spawns correctly), and users can check error_num (i.e. golang's exec.Cmd.Wait()) to see how it exited. This preserves previous behavior, which basically was that start was always successful if the thing actually launched. Since we never kept track of exit codes, this would always succeed too. Now that we do, it doesn't, and this change is required. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
error_num seems to be trying to remember the exit code of the init process, except that nothing actually keeps track of it anywhere. So, let's add a field to the handler, so that we can keep track of the process' exit status, and the propagate it to error_num in struct lxc_container so that people can use it. Note that this is a slight behavior change, essentially instead of making error_num always == the return code from start, now it contains slightly more useful information (the actual exit status). But, there is only one internal user of error_num which I'll fix in later in the series, so IMO this is ok. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
Based on the comments in the code (and the have_status flag), the intent here (and IMO, the desired behavior) should be for init.lxc to propagate the actual exit code from the real application process up through. Otherwise, it is swallowed and nobody can access it. The bug being fixed here is that ret held the correct exit code, but when it went around the loop again (to wait for other children) ret is clobbered. Let's save the desired exit status somewhere else, so it can't get clobbered, and we propagate things correctly. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
The documentation for this function says if the task was killed by a signal, the return code will be 128+n, where n is the signal number. Let's make that actually true. (We'll use this behavior in later patches.) Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
This non-init forwarding check should really be before all the log messages about "init continued" or "init stopped", since they will otherwise lie about some process that wasn't init being stopped or continued. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Closes #2027. Closes lxc/go-lxc#98. Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Kaarle Ritvanen authored
Signed-off-by:Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
- int lxc_make_controlling_pty() - int lxc_login_pty() - void lxc_pty_conf_free() - void lxc_pty_info_init() - void lxc_pty_init() Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Tycho Andersen authored
otherwise, we just get a return value of false from setting config failure, with no indication as to what actually failed in the log. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Tycho Andersen authored
* exit(1) when there is an option parsing error * exit(0) when the user explicitly asks for help * exit(1) when the user specifies an invalid option Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
LiFeng authored
If 'lxc_cmd_get_name' failed and return with NULL, this would cause a segment fault. Signed-off-by:LiFeng <lifeng68@huawei.com>
-
Stéphane Graber authored
Signed-off-by:Stéphane Graber <stgraber@ubuntu.com>
-
Stéphane Graber authored
Signed-off-by:Stéphane Graber <stgraber@ubuntu.com>
-
Christian Brauner authored
When we deleted cgroups for unprivileged containers we used to allocate a new mapping and clone a new user namespace each time we delete a cgroup. This of course meant - on a cgroup v1 system - doing this >= 10 times when all controllers were used. Let's not to do this and only allocate and establish a mapping once. Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
When fully unprivileged users run a container that only maps their own {g,u}id and they do not have access to setuid new{g,u}idmap binaries we will write the idmapping directly. This however requires us to write "deny" to /proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be denied. On a sidenote, this patch enables fully unprivileged containers. If you now set lxc.net.[i].type = empty no privilege whatsoever is required to run a container. Enhances #2033. Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com>
-
Serge Hallyn authored
The existing check doesn't work, because when you statically link a program against libc, any functions not called are not included. So cap_init() which we check for is not there in the built binary. So instead just check whether a "gcc -lcap -static" works. If libcap.a is not available it will fail, if it is it will succeed. Signed-off-by:Serge Hallyn <shallyn@cisco.com>
-
Stéphane Graber authored
Signed-off-by:Stéphane Graber <stgraber@ubuntu.com>
-
Christian Brauner authored
Closes #2033. Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-