[lxc-devel] [PATCH RFC] log: introduce container logging

Serge Hallyn serge.hallyn at ubuntu.com
Wed Mar 12 15:02:16 UTC 2014


Quoting S.Çağlar Onur (caglar at 10ur.org):
> Hi Serge,
> 
> On Tue, Mar 11, 2014 at 8:13 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > This is not intended to be applied yet.
> >
> > This patch adds real per-container, thread-safe log preferences.  Currently
> > if a program loads two containers which both set a lxc.logfile, and start
> > then start them in sequence, the logfile for the second container will be
> > used.  This patch stores the log preferences in the lxc_container itself.
> > It leaves ERROR/INFO/etc as global log print helpers, while the new
> > CERROR/CINFO/etc become new per-container helpers.  To demonstrate how to
> > use these, some logging in lxcapi_start and lxcapi_create has been
> > converted.
> >
> > What this patch ignores, and why I say this patch is not ready to be
> > applied, is what to do about 'lxc-start -l info -o outfile'.  With this
> > patch, global logging (ERROR) will go to outfile, while per-container
> > logging will not.
> 
> Wow, I didn't see that coming as I was thinking you were joking the
> other day :) One possible solution to this global v.s per-container
> logging problem could be using a well known global log file and
> introducing a new argument to override it.
> 
> We could say that LXC_LOGPATH/lxc.log will have the global logs and
> logfile parameter will have the per-container logs. I guess the
> downside of this approach would be looking 2 different log files in 2
> different locations in case of a failure.
> 
> Do you think we have lots of code that does something before we create
> an lxc_container struct? I could be wrong but I suspect we don't have
> much in as we almost have the lxc_container around all the time. So
> maybe we can make everything per-container level.

My thought was that anything relating to the starting, stopping,
running, or lxc-monitor for a container would go to the per-container
log.  If things break while constructing the lxc_container, i.e. we
can't read the config file, that goes to the global log.  You might
be right that it is best to always use LXC_LOGPATH/lxc.log for the
global log, or maybe even just LXCPATH/lxc.log, to minimize the
amount of looking around we have to do when something fails.

There is a practical problem.  We have lots of helper functions
which don't get a lxc_container passed to them.  Some don't even
get an lxc_conf.  Three obvious ways to fix that would be

1. always pass a lxc_container * everywhere.  Don't like that.

2. keep a per-thread 'current lxc_container *', kind of like current
in the kernel.  The main downside to this is the question of what
it means for lxc_container refcounts.

3. keep a per-thread 'last error'.  Then whenever we get to a
function where we have the lxc_container * we can log and discard
the last error(s).

None of these is ideal.  I think (3) is what I was thinking a year
ago or so, except I thought it would live in the lxc_container
itself.

-serge


More information about the lxc-devel mailing list