Introduce a new -F option (no-op for now) as an opposite of -d.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This hides some of the confusing "command X failed to receive response"
why are usually caused by another more understandable error.
On failure to start() from lxc-start, a new error message is displayed,
suggesting the user sets logfile and loglevel and if using -d, restarts
the container in the foreground instead.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
So that exit status doesn't show up as 255.
Reported-by: Andrey Khozov <avkhozov@googlemail.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The fds for stdin,stdout,stderr that we were leaving open for /sbin/init
in the container were those from /dev/tty or lxc.console (if given), which
wasn't right. Inside the container it should only have access to the pty
that lxc creates representing the console.
This was noticed because busybox's init was resetting the termio on its
stdin which was effecting the actual users terminal instead of the pty.
This meant it was setting icanon so were were not passing keystrokes
immediately to the pty, and hence command line history/editing wasn't
working.
Fix by dup'ing the console pty to stdin,stdout,stderr just before
exec()ing /sbin/init. Fix fd leak in error handling that I noticed while
going through this code.
Also tested with lxc.console = none, lxc.console = /dev/tty7 and no
lxc.console specified.
V2: The first version was getting EBADF sometimes on dup2() because
lxc_console_set_stdfds() was being called after lxc_check_inherited()
had already closed the fds for the pty. Fix by calling
lxc_check_inherited() as late as possible which also extends coverage
of open fd checked code.
V3: Don't move lxc_check_inherited() since it needs to be called while
the tmp proc mount is still mounted. Move call to lxc_console_set_stdfds()
just before it.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
The fds for stdin,stdout,stderr that we were leaving open for /sbin/init
in the container were those from /dev/tty or lxc.console (if given), which
wasn't right. Inside the container it should only have access to the pty
that lxc creates representing the console.
This was noticed because busybox's init was resetting the termio on its
stdin which was effecting the actual users terminal instead of the pty.
This meant it was setting icanon so were were not passing keystrokes
immediately to the pty, and hence command line history/editing wasn't
working.
Fix by dup'ing the console pty to stdin,stdout,stderr just before
exec()ing /sbin/init. Fix fd leak in error handling that I noticed while
going through this code.
Also tested with lxc.console = none, lxc.console = /dev/tty7 and no
lxc.console specified.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This sets lxc_log_define to what should be appropriate values for all
existing binaries that call lxc_log_init.
The name is lxc_<bin name>_ui for anything that's user visible and
lxc_<bin name> for anything that's not.
The parent is set to "lxc" for anything using the API and to the
matching C file name for anything that isn't.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
In current LXC, loglevel and logfile are write-once functions.
That behaviour was appropriate when those two were first introduced
(pre-API) but with current API, one would expect to be able to
set_config_item those multiple times.
So instead, introduce lxc_log_options_no_override which when called
turns those two config keys read-only and have all existing binaries
which use log_init call that function once they're done setting the
value requested by the user.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This fixes various compile errors when building with musl libc. For
example:
In file included from start.c:66:0:
monitor.h:38:12: error: 'NAME_MAX' undeclared here (not in a function)
char name[NAME_MAX+1];
^
start.c: In function 'setup_signal_fd':
start.c:202:2: error: implicit declaration of function 'sigfillset' [-Werror=implicit-function-declaration]
if (sigfillset(&mask) ||
^
...
In file included from freezer.c:36:0:
monitor.h:39:12: error: 'NAME_MAX' undeclared here (not in a function)
char name[NAME_MAX+1];
^
...
In file included from cgroup.c:45:0:
conf.h:87:13: error: 'IFNAMSIZ' undeclared here (not in a function)
char veth1[IFNAMSIZ]; /* needed for deconf */
^
cgroup.c: In function 'find_cgroup_subsystems':
cgroup.c:230:3: error: implicit declaration of function 'strdup' [-Werror=implicit-function-declaration]
(*kernel_subsystems)[kernel_subsystems_count] = strdup(line);
^
...
In file included from conf.c:65:0:
conf.h:87:13: error: 'IFNAMSIZ' undeclared here (not in a function)
char veth1[IFNAMSIZ]; /* needed for deconf */
^
In file included from conf.c:66:0:
conf.c: In function 'run_buffer':
log.h:263:9: error: implicit declaration of function 'strsignal' [-Werror=implicit-function-declaration]
struct lxc_log_locinfo locinfo = LXC_LOG_LOCINFO_INIT; \
^
...
af_unix.c: In function 'lxc_abstract_unix_send_credential':
af_unix.c:208:9: error: variable 'cred' has initializer but incomplete type
struct ucred cred = {
^
af_unix.c:209:3: error: unknown field 'pid' specified in initializer
.pid = getpid(),
^
af_unix.c:209:3: error: excess elements in struct initializer [-Werror]
af_unix.c:209:3: error: (near initialization for 'cred') [-Werror]
af_unix.c:210:3: error: unknown field 'uid' specified in initializer
.uid = getuid(),
^
af_unix.c:210:3: error: excess elements in struct initializer [-Werror]
af_unix.c:210:3: error: (near initialization for 'cred') [-Werror]
af_unix.c:211:3: error: unknown field 'gid' specified in initializer
.gid = getgid(),
^
and more...
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
When you start a container in daemon model, you have at least
3 processes:
1. The command the user start (lxc-start -d)
2. The backgrounded fork of that command after start() is done
3. The container init process
In PID file, we need (2), but currently we are writing (1),
this is wrong because (1) exits as soon as the container is
started, it's complately useless.
So we write pid after daemonize, so that we'll always write
the right pid to PID file.
Reported-by: Stephane Graber <stgraber@ubuntu.com>
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
So we can remove PID file untill lxc_container_free.
This also fix bug: https://github.com/lxc/lxc/issues/89
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Pretty much the only case where we do NOT want to daemonize
a container start is lxc-start. So make c->daemonize true
by default, and have lxc-start set it to false.
If there are existing API users who rely on daemonize by
default, then they will be broken by this. It seems we should
do this before beta1 if we're going to do it.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
As mentioned in a previous commit, this does two changes:
- Make want_daemonize return a bool (false on failure, true on success)
- Make both want_daemonize and want_close_all_fds take a "state"
argument so the user can choose to unset those flags.
This commit also updates all occurences of those two functions and turns
the daemonize attribute from an int to a bool.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
To do this, add a c->clear_config() helper to the api.
(this fixes the bug https://bugs.launchpad.net/bugs/1251352)
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Right now lxc-start always does one of two things: it creates
a new namespace or inherits it from the parent environment.
This patch adds a third option: share a namespace with another
container (actually: a process).
In some situations this is handy. For example by sharing a network
namespace it is possible to migrate services between containers
without (or with little) downtime.
This patch creates an infrastructure for inheriting any type
of namespace, but only the network namespace is supported for now.
The idea was simply misguided.
If you provide a custom configuration file, you still should be
putting the command sock into the real lxcpath, not an 'anon' one.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The API header was included in a variety of ways before, standardize
those to "include <lxc/lxccontainer.h>" as this will always work both in
tree and on a system with the headers installed.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Being able to set close_all_fds via API would be usefull for the
situations like running an application (let's say web server)
that controls the lifecycle of the container using the LXC API.
We don't want forked process to inherit parent's resource (file, socket, ...)
Signed-off-by: S.Çağlar Onur <caglar@10ur.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Normal lxc-start usage tends to be "lxc-start -n name [-P lxcpath]".
This causes $lxcpath/$name/config to be the configuration for the
container. However, lxc-start is more flexible than that. You can
specify a custom configuration file, in which case $lxcpath/$name/config
is not used. You can also (in addition or in place of either of these)
specify configuration entries one-by-one using "-s lxc.utsname=xxx".
To support this using the API, if we are not using
$lxcpath/$name/config then we put ourselves into a custom lxcpath
called (configurable using LXCPATH) /var/lib/lxc_anon. To stop a
container so created, then, you would use
lxc-stop -P /var/lib/lxc_anon -n name
TODO: we should walk over the list of &defines by hand and set them
using c->set_config_item. I haven't done that in this patch.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
When doing reboot test, must add clone_newuser to clone flags, else
we can't clone(CLONE_NEWPID).
If we don't have caps at lxc-start, don't refuse to start. Drop the
lxc_caps_check() function altogether as it is unused now.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
When running lxc-start command with valgrind, it reports a memory leak error.
When lxc-start command fails, the conf which is from malloc has not been released.
This patch fix the problem.
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
On Fri, 26 Apr 2013 10:18:12 -0500
Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> Quoting Dwight Engen (dwight.engen@oracle.com):
> > On Fri, 26 Apr 2013 09:37:49 -0500
> > Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> >
> > > Quoting Dwight Engen (dwight.engen@oracle.com):
> > > > Using lxc configured with --enable-configpath-log, and
> > > > specifying a path to the lxc commands with -P, the log file
> > > > path is generated with a basename of LOGPATH instead of the
> > > > lxcpath. This means for example if you do
> > > >
> > > > lxc-start -P /tmp/containers -n test01 -l INFO
> > > >
> > > > your log file will be
> > > >
> > > > /var/lib/lxc/test01/test01.log
> > > >
> > > > I was expecting the log to be /tmp/containers/test01/test01.log.
> > > > This is particularly confusing if you also have test01 on the
> > > > regular lxcpath. The patch below changes the log file path to be
> > > > based on lxcpath rather than LOGPATH when lxc is configured with
> > > > --enable-configpath-log.
> > > >
> > > > I think that even in the normal non --enable-configpath-log case
> > > > we should consider using lxcpath as the base and not having
> > > > LOGPATH at all, as attempting to create the log files
> > > > in /var/log is not going to work for regular users on their own
> > > > lxcpath. If we want that, I'll update the patch to do that as
> > > > well.
> > >
> > >
> > > Perhaps we should do:
> > >
> > > 1. If lxcpath == default_lxc_path(), then first choice is
> > > LOGPATH, second is lxcpath/container.log
> > > 2. when opening, if first choice fails, use second choice
> > > if there is any.
> > >
> > > That way 'system' containers will go to /var/log/lxc, as I think
> > > they should. Custom-lxcpath containers should never go
> > > to /var/log/lxc, since their names could be dups of containers in
> > > default_lxc_path(). And if the system is a weird one where
> > > default_lxc_path is set up so that an unprivileged user can use
> > > it, then we should log into $lxcpath.
> >
> > That sounds good to me. So these rules would apply in both the
> > regular and --enable-configpath-log cases.
I updated the patch to try to open the log file according to the
choices given above. Along the way I cleaned up log.c a bit, making
some things static, grouping external interfaces together, etc...
Hopefully that doesn't add too much noise.
> > > (Note this patch will trivially conflict with my new lxc_clone.c
> > > causing it to fail to build - unfortunate result of timing)
> >
> > Yeah unfortunately this touches every lxc_log_init() caller. I can
> > work on the above logic and re-submit after your new lxc_clone
> > stuff goes in.
>
> No no, I'll just need to remember to update mine. Don't hold up on
> mine, this is just the nature of such collaboration :)
>
> > Did you have any thoughts on the XXX what to pass in for lxcpath in
> > lxc_init? Right now it just falls back to LOGPATH.
>
> No - that's a weird one, since lxc_init runs in the container. If
> there were only system containers I'd say always use LOGPATH.
> However there are people (apparently :) who use container sharing the
> host's rootfs...
>
> lxc-execute does know the lxcpath. Perhaps we can simply have
> src/lxc/execute.c:execute_start() look at handler->conf to see if a
> rootfs is set. If rootfs is NOT set, then pass lxcpath along to
> lxc-init. Then lxc-init can mostly do the same as the others? (It
> doesn't use src/lxc/arguments.c, so you'd have to add lxcpath to
> options[] in lxc-init.c)
So I did this, only to realize that lxc-init is passing "none" for the
file anyway, so it currently doesn't intend to log. This makes me
think that passing NULL for lxcpath is the right thing to do in
this patch. If you want me to make it so lxc-init can log, I can do
that but I think it should be in a different change :)
--
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
For the lxc-* C binaries, introduce a -P|--lxcpath command line option
to override the system default.
With this, I can
lxc-create -t ubuntu -n r1
lxc-create -t ubuntu -n r1 -P /home/ubuntu/lxcbase
lxc-start -n r1 -d
lxc-start -n r1 -d -P /home/ubuntu/lxcbase
lxc-console -n r1 -d -P /home/ubuntu/lxcbase
lxc-stop -n r1
all working with the right containers (module cgroup stuff).
To do:
* lxc monitor needs to be made to handle cgroups.
This is another very invasive one. I started doing this as
a part of this set, but that gets hairy, so I'm sending this
separately. Note that lxc-wait and lxc-monitor don't work
without this, and there may be niggles in what I said works
above - since start.c is doing lxc_monitor_send_state etc
to the shared abstract unix domain socket.
* Need to handle the cgroup conflicts.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The previous lxcpath patches added support for a custom LXCPATH set
through a system-wide configuration file.
This was also exposed through the C api, so that a custom lxcpath could
be set at the container object instanciation time, or set at runtime.
However the command sock filename was always located under the global
lxcpath, which could be confusing, and would be a problem for users
with insufficient perms to the system-wide lxc path (i.e. if setting
lxcpath to $HOME/lxcbase). This patch changes that by passing the
lxcpath to all callers of lxc_command().
It remains to add an lxcpath command line argument to most of the
command line tools (which are not using the C api) - lxc-start,
lxc-info, lxc-stop, etc.
At this point it becomes tempting to do something like
c = lxc.Container("r1", "/var/lib/lxc")
c2 = lxc.Container("r1", "$HOME/lxcbase")
However, that's problematic - those two will use the same directory
names for cgroup directories.
What would be the best way to handle this? One way (which I kind
of like) is to give up on naming the cgroups after the container.
use mkstemp for the cgroup name, let lxc keep track of the cgroup
name based on the command socket, and make users use lxc-cgroup to get
and change settings.
Other ideas?
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Here is a patch to introduce a configurable system-wide
lxcpath. It seems to work with lxc-create, lxc-start,
and basic python3 lxc usage through the api.
For shell functions, a new /usr/share/lxc/lxc.functions is
introduced which sets some of the basic global variables,
including evaluating the right place for lxc_path.
I have not converted any of the other python code, as I was
not sure where we should keep the common functions (i.e.
for now just default_lxc_path()).
configure.ac: add an option for setting the global config file name.
utils: add a default_lxc_path() function
Use default_lxc_path in .c files
define get_lxc_path() and set_lxc_path() in C api
use get_lxc_path() in lua api
create sh helper for getting default path from config file
fix up scripts to use lxc.functions
Changelog:
feb6:
fix lxc_path in lxc.functions
utils.c: as Dwight pointed out, don't close a NULL fin.
utils.c: fix the parsing of lxcpath line
lxc-start: print which rcfile we are using
commands.c: As Dwight alluded to, the sockname handling was just
ridiculous. Clean that up.
use Dwight's recommendation for lxc.functions path: $datadir/lxc
make lxccontainer->get_config_path() return const char *
Per Dwight's suggestion, much nicer than returning strdup.
feb6 (v2):
lxccontainer: set c->config_path before using it.
convert legacy lxc-ls
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Until now, if a lxc-* (i.e. lxc-start) command did not specify a logfile
(with -o logfile), the default was effectively 'none'. With this patch,
the default becomes a per-container log file.
If a container config file specifies 'lxc.logfile', that will override
the default. If a '-o logfile' argument is specifed at lxc-start,
then that will override both the default and the configuration file
entry. Finally, '-o none' can be used to avoid having a logfile at
all (in other words, the previous default), and that will override
a lxc.logfile entry in the container configuration file.
If the user does not have rights to open the default, then 'none' will
be used. However, in that case an error will show up on console. (We
can work on removing that if it annoys people, but I think it is
helpful, at least while we're still ironing this set out) If the user
or container configuration file specified a logfile, and the user does
not have rights to open the default, then the action will fail.
One slight "mis-behavior" which I have not fixed (and may not fix) is
that if a lxc.logfile is specified, the default logfile will still
get created before we read the configuration file to find out there
is a lxc.logfile entry.
changelog: Jan 24:
add --enable-configpath-log configure option
When we log to /var/lib/lxc/$container/$container.log, several things
need to be done differently than when we log into /var/log/lxc (for
instance). So give it a configure option so we know what to do
When the user specifies a logfile, we bail if we can't open it. But
when opening the default logfile, the user may not have rights to
open it, so in that case ignore it and continue as if using 'none'.
When using /var/lib/lxc/$c/$c.log, we use $LOGPATH/$name/$name.log.
Otherwise, we use $LOGPATH/$name.log.
When using /var/lib/lxc/$c/$c.log, don't try to create the log path
/var/lib/lxc/$c. It can only not exist if the container doesn't
exist. We don't want to create the directory in that case. When
using /var/log/lxc, then we do want to create the path if it does
not exist.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The logfile changes broke lxc-info and possibly more command line
tools. Revert for now until we get those issues addressed.
This reverts commit 74476cf144.
[ Thanks to Stéphane and Dwight for the feedback on the previous patch ]
Until now, if a lxc-* (i.e. lxc-start) command did not specify a logfile
(with -o logfile), the default was effectively 'none'. With this patch,
the default becomes $LOGPATH/<container>/<container>.log. LOGPATH is
specified at configure time with '--with-log-path='. If unspecified, it
is $LXCPATH, so that logs for container r2 will show up at
/var/lib/lxc/r2/r2/log. LOGPATH must exist, while lxc will make sure to
create $LOGPATH/<name>. As another example, Ubuntu will likely specify
--with-log-path=/var/log/lxc (and place /var/log/lxc into
debian/lxc.dirs), placing r2's logs in /var/log/lxc/r2/r2.log.
If a container config file specifies 'lxc.logfile', that will override
the default. If a '-o logfile' argument is specifed at lxc-start,
then that will override both the default and the configuration file
entry. Finally, '-o none' can be used to avoid having a logfile at
all (in other words, the previous default), and that will override
a lxc.logfile entry in the container configuration file.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Ok... Here's the patch again. Since Serge is removing the loglevel
structure member, this patch no longer references that element.
From the original description:
1) Removes run_makedev() and the call to it from conf.c per discussion.
2) Adds an lxc.hook.autodev hook.
Note: This hook is very close (one routine level abstracted) from where
the run_makedev was called. Anyone really rrreeeaaalllyyy needing
MAKEDEV can add it in with a small shim script to do whatever they want
under whatever distro they're using, so no functionality is lost there.
3) Added a number of environment variables for all the hook scripts to
reference to assist in execution. Things like LXC_ROOTFS_MOUNT could be
very useful but others were added as well. Room for more if anyone has
an itch. All in one spot in lxc_start.c.
4) clearenv and putenv( "container=lxc" ) calls were moved to just after
the "start" hook in the container just prior to actually firing up the
container so we could use environment variables prior to that and have
them flushed them before firing up init. Nice side effect is that you
can define environment variables and then call lxc-start and have them
show up in those hooks scripts.
5) I actually DID update the man page for lxc.conf! I guess I lied when
I said I wouldn't get that done.
[... and ...]
I added the rcfile to the lxc_conf structure as suggested and moved the
setenv bundle from lxc-start.c over to start.c just prior to calling
run_lxc_hooks for the pre-start hook.
Signed-off-by: Michael H. Warfield <mhw@WittsEnd.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
lxc-start -c makes the named file/device the container's console, but using
this with a regular file in order to get a log of the console output does
not work very well if you also want to login on the console. This change
implements an additional option (-L) to simply log the console's output to
a file.
Both options can be used separately or together. For example to get a usable
console and log: lxc-start -n name -c /dev/tty8 -L console.log
The console state is cleaned up more when lxc_delete_console is called, and
some of the clean up paths in lxc_create_console were fixed.
The lxc_priv and lxc_unpriv macros were modified to make use of gcc's local
label feature so they can be expanded more than once in the same function.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
