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

[Serge Hallyn]

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

No no, I'll just need to remember to update mine.  Don't hold up on
mine, this is just the nature of such collaboration  :)

> 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.

No - that's a weird one, since lxc_init runs in the container.  If there
were only system containers I'd say always use LOGPATH.  However there
are people (apparently :) who use container sharing the host's rootfs...

lxc-execute does know the lxcpath.  Perhaps we can simply have
src/lxc/execute.c:execute_start() look at handler->conf to see if a
rootfs is set.  If rootfs is NOT set, then pass lxcpath along to
lxc-init.  Then lxc-init can mostly do the same as the others?  (It
doesn't use src/lxc/arguments.c, so you'd have to add lxcpath to
options[] in lxc-init.c)