[lxc-devel] [lxc/lxc] 858377: logs: introduce a thread-local 'current' lxc_confi...
GitHub
noreply at github.com
Wed Apr 22 16:55:55 UTC 2015
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: 858377e4d968c8a7254e22dc7167acf76ac91a48
https://github.com/lxc/lxc/commit/858377e4d968c8a7254e22dc7167acf76ac91a48
Author: Serge Hallyn <serge.hallyn at ubuntu.com>
Date: 2015-04-22 (Wed, 22 Apr 2015)
Changed paths:
M src/lxc/Makefile.am
M src/lxc/conf.c
M src/lxc/conf.h
M src/lxc/confile.c
M src/lxc/log.c
M src/lxc/log.h
M src/lxc/lxccontainer.c
M src/lxc/start.c
Log Message:
-----------
logs: introduce a thread-local 'current' lxc_config (v2)
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.
Changelog (2015-04-21):
. always re-set current_config to NULL at end of an API
call, rather than storing the previous value. We don't
nest API calls.
. remove the log_lock stuff which wasn't used
. lxc_conf_free: if the config is current_config, set
current_config to NULL. (It can't be another thread's
current_config, or we wouldn't be freeing it)
. lxc_check_inherited: don't close fd if it is the
current_config->logfd. Note this is only called when
starting a container, so we have no other threads at
this point.
Changelog (2015-04-22)
. Unset the per-container logfd on destroy
.
. Do so before we rm the containerdir. Otherwise if the logfile is set
. to $lxcpath/$name/log, the containerdir won't be fully deleted.
Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
Acked-by: Stéphane Graber <stgraber at ubuntu.com>
Commit: 2366b8a769b9403fda3c4780c84ad87d07b21d7e
https://github.com/lxc/lxc/commit/2366b8a769b9403fda3c4780c84ad87d07b21d7e
Author: Serge Hallyn <serge.hallyn at ubuntu.com>
Date: 2015-04-22 (Wed, 22 Apr 2015)
Changed paths:
M src/lxc/cgmanager.c
M src/lxc/lxc.h
M src/lxc/lxc_monitor.c
M src/lxc/monitor.c
M src/lxc/monitor.h
Log Message:
-----------
use poll instead of select
Particularly when using the go-lxc api with lots of threads, it
happens that if the open files limit is > 1024, we will try to
select on fd > 1024 which breaks on glibc.
So use poll instead of select.
Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
Acked-by: Stéphane Graber <stgraber at ubuntu.com>
Compare: https://github.com/lxc/lxc/compare/ed52814c7769...2366b8a769b9
More information about the lxc-devel
mailing list