[lxc-devel] [PATCH] Use lxcpath for basename of log when --enable-configpath-log

[Dwight Engen]

On Fri, 26 Apr 2013 09:37:49 -0500
Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> Quoting Dwight Engen (dwight.engen at 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.
 
> (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.

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.