[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