1. 30 Apr, 2013 2 commits
    • Create log file in lxcpath for non-system containers · ab1bf971
      Dwight Engen authored
      On Fri, 26 Apr 2013 10:18:12 -0500
      Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
      
      > Quoting Dwight Engen (dwight.engen@oracle.com):
      > > On Fri, 26 Apr 2013 09:37:49 -0500
      > > Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
      > >
      > > > Quoting Dwight Engen (dwight.engen@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.
      
      I updated the patch to try to open the log file according to the
      choices given above. Along the way I cleaned up log.c a bit, making
      some things static, grouping external interfaces together, etc...
      Hopefully that doesn't add too much noise.
      
      > > > (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)
      
      So I did this, only to realize that lxc-init is passing "none" for the
      file anyway, so it currently doesn't intend to log. This makes me
      think that passing NULL for lxcpath is the right thing to do in
      this patch. If you want me to make it so lxc-init can log, I can do
      that but I think it should be in a different change :)
      
      --
      Signed-off-by: 's avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
    • fix building docs · 7f951458
      Dwight Engen authored
      Commit 69fe23ff added checking for the older docbook2man back into
      configure, but this breaks building the docs on at least Oracle Linux and
      Fedora when docbook2X is not installed as docbook2man will be found but the
      docs don't actually build with that tool.
      
      This change makes it so the docs can be built with either the older
      docbook2man or the newer 2X tools by using configure to set the dtd
      string to an appropriate value depending on use of docbook2man or
      db2x_docbook2man.
      
      Also fixed a small error in lxc-destroy.sgml.in that was noticed
      by the old tools.
      Signed-off-by: 's avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  2. 26 Apr, 2013 2 commits
    • add zfs support to lxc-create and lxc-destroy · 33c2c3ec
      Serge Hallyn authored
      This is based on patch from Papp Tamas (thanks).  It also does some
      reorganizing of lxc-create to commonize some of the backingstore handling.
      
      I played with it using:
      
      	sudo lvcreate -L 100G -n zfs vg0
      	sudo zpool create lxc /dev/vg0/zfs
      	sudo lxc-create -B zfs --zfsroot lxc -t ubuntu -n dir2
      
      or you could
      
      	qemu-img create zfs.img 100G
      	sudo qemu-nbd -c /dev/nbd0 zfs.img
      	sudo zpool create lxc /dev/nbd0
      	sudo lxc-create -B zfs --zfsroot lxc -t ubuntu -n dir2
      
      I'll write the bdev.c handler and hook up lxc-clone next.
      
      This also fixses a bug in the sed expression to extract the rootfs from
      container config, which prepended an extra '/' to the rootdev.  (That
      caused the zfs list entry not to match at destroy)
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Cc: Papp Tamas <tompos@martos.bme.hu>
      Acked-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
    • lxc_wait should start monitord · f485f377
      Dwight Engen authored
      If lxc_wait is called before the container has started the socket will not
      yet have been created and lxc_wait's connect to it will fail. Starting the
      daemon will create the socket for lxc_wait to connect to.
      Signed-off-by: 's avatarDwight Engen <dwight.engen@oracle.com>
      Acked-by: 's avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
  3. 25 Apr, 2013 6 commits
  4. 24 Apr, 2013 7 commits
  5. 23 Apr, 2013 3 commits
  6. 22 Apr, 2013 5 commits
  7. 21 Apr, 2013 1 commit
  8. 18 Apr, 2013 6 commits
  9. 17 Apr, 2013 3 commits
  10. 16 Apr, 2013 5 commits