[lxc-devel] [PATCH] logging: Add lxc_log_options_no_override function

Thu Feb 6 19:15:07 UTC 2014

On Thu, Feb 06, 2014 at 11:39:41AM -0600, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber at ubuntu.com):
> > On Tue, Feb 04, 2014 at 04:52:16PM -0600, Serge Hallyn wrote:
> > > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > > > Perhaps the right thing to do is
> > > > > . make loglevel and logfile per-thread
> > > > > . store the lxc.loglevel from config file into c->loglevel, and NOT set
> > > > >   it globally (in per-thread)
> > > > > . at lxcapi_create and lxcapi_start, set the global loglevel to the
> > > > >   c->loglevel (if defined), and reset at end.
> > > > 
> > > > Is that you volunteering? :)
> > > 
> > > /me nonchalantly takes a step back
> > > 
> > > > More seriously, I've spent the last 30min or so looking at my screen
> > > > trying to figure out a vaguely sane way out of our current logging
> > > > nightmare and haven't found a magic way out yet.
> > > > 
> > > > So we clearly have two kind of things we want to log:
> > > >  - Container related messages (99% of what we log)
> > > >  - Non-container stuff (the odd 1% that we don't know where to log)
> > > > 
> > > > We also have two ways of setting where to log things:
> > > >  - Command line argument to the binaries
> > > >  - Container config options
> > > > 
> > > > So now for the easy cases. If a user passes a command line argument, we
> > > > expect that to apply to both any log entry and override any
> > > > per-container setting we may have.
> > > > 
> > > > For the case where the user doesn't, I think we should have a global
> > > > lxc.logfile and lxc.loglevel which tells LXC what to do with those log
> > > > entries that aren't container-related and for the container-related
> > > > ones, send them to whatever's set in the container config (or in our
> > > > hardcoded defaults).
> > > 
> > > Hm, that's a good idea, and actually if we let it be set through
> > > either /etc/lxc/lxc.conf or through environment, so I could do
> > > 
> > > LXC_LOGLEVEL=INFO LXC_LOGFILE=/tmp/a lxc-ls
> > > 
> > > that would rock.
> > > 
> > > > Now I think the above is what we WANT, the question is how to do it,
> > > > that's where it gets tricky...
> > > > 
> > > > So clearly we want to split the two kinds of logging functions
> > > > (container, non-container), have the former look at the container's
> > > > loglevel and logfile and the latter look at the global loglevel and
> > > > logfile with all of those being overriddable (from the command line).
> > > > 
> > > > The obvious problem there is how to lookup the per-container loglevel
> > > > and logfile without having to get struct container passed to every
> > > > single function in our codebase. That's where I'm kind of stuck, so far
> > > > the best I can come up with is to have LXC use global variables
> > > > (possibly TLS) to store the current container being handled, making sure
> > > > all relevant functions set/clear those variables appropriately and then
> > > > have them used by the logging functions.
> > > 
> > > Right, I don't think we want to be carrying a piece of state around
> > > to all functions just for logging info.  I think a per-thread instance
> > > of those variables is the way to go.
> > > 
> > > I think if a user sets lxc.loglevel in a container config, the only
> > > things they want logged there are things during lxcapi_start, and
> > > *maybe* during create or destroy, those I'm not sure about those.
> > > So the task of set/unseting the per-thread loglevel/loginfo should
> > > actually not be daunting.
> > 
> > Right, when I set lxc.logfile and lxc.loglevel in a container's config,
> > I expect anything related to the container's life cycle to go to that
> > log file which isn't necessarily everything we do.
> > 
> > I guess I'd at least expect:
> >  - config parsing (load_config, clear_config, {get|set}_config_item, ...)
> 
> If lxc-start is run with -l trace -o outout, overriding the values
> in the container config, and then a separate program using the api
> updates config values and writes a new config, this can't respect
> the override values for the running container.

Sure, I wouldn't expect it to magically change the location and level
for log entries coming from the already running lxc-start background
process. Just that we in theory could have all API commands attempt to
get loglevel+logfile from the container config and use that for
subsequent log entries.

Sending pretty much everything but start/stop to a global log file will
make it very hard to figure out what container the log entry is about.

> To keep this sane, I would rather say that anything relating to
> creating/destroying a container, or changing its values, goes to
> whatever is set as a global value either in the api or by the
> callign program.  Only things pertaining to container startup,
> running and shutdown go to the values in the container configuration
> file (unless overridden).

I guess I'm fine with this as it's better than nothing and so long as
the default for the global loglevel is error and default fo logfile is
stderr, we won't have the problem of the unreadable log file as things
will go to stderr as they happen.

> 
> In which case, again, this should be pretty simple to do with a
> per-thread pair of variables which are set at lxcapi_start top
> and re-set at its bottom.
> 
> >  - start
> >  - stop
> 
> -serge
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140206/19b04041/attachment-0001.pgp>