Thanks, Steve. On Mon, Apr 18, 2016 at 10:59:37PM -0000, Steve Langasek wrote: > Tycho, > > lxd logs attached. > > ** Attachment added: "1571082-lxd-logs.tar.xz" > > https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1571082/+attachment/4639541/+files/1571082-lxd-logs.tar.xz
Unfortunately, there's not a lot to go on here. lxc.log is basically empty, but doesn't log any failures. lxd's log does have: t=2016-04-16T21:51:34+0000 lvl=info msg=handling method=POST url=/1.0/images ip=10.0.8.1:38476 t=2016-04-16T21:51:34+0000 lvl=info msg=handling url=/1.0/operations/7d063725-8b02-4b53-9315-b1a2ee4b3a30/wait ip=10.0.8.1:38476 method=GET t=2016-04-16T21:51:34+0000 lvl=info msg=handling method=GET url="/1.0/events?type=operation" ip=10.0.8.1:38482 t=2016-04-16T21:51:34+0000 lvl=info msg="Image not in the db, downloading it" image=6cb0ba80a5fe32357568a473cbaf69f14d26da0ba6b08f5b1bcde7053fc73757 server=https://cloud-images.ubuntu.com/releases/ t=2016-04-16T21:51:34+0000 lvl=info msg="Downloading the image" image=6cb0ba80a5fe32357568a473cbaf69f14d26da0ba6b08f5b1bcde7053fc73757 t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=DELETE url=/1.0/images/aliases/ubuntu-xenial ip=10.0.8.1:38476 t=2016-04-16T21:51:38+0000 lvl=info msg=handling ip=10.0.8.1:38476 method=POST url=/1.0/images/aliases t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=GET url=/1.0 ip=10.0.8.1:38476 t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=GET url=/1.0/images/aliases/ubuntu-xenial ip=10.0.8.1:38476 t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=GET url=/1.0/images/6cb0ba80a5fe32357568a473cbaf69f14d26da0ba6b08f5b1bcde7053fc73757 ip=10.0.8.1:38476 t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=POST url=/1.0/containers ip=10.0.8.1:38476 t=2016-04-16T21:51:38+0000 lvl=info msg=handling method=GET url=/1.0/operations/957e84a5-538e-4ef6-a8ce-20e113d04cce/wait ip=10.0.8.1:38476 t=2016-04-16T21:52:04+0000 lvl=info msg=handling method=GET url="/1.0/containers?recursion=1" ip=10.0.8.1:38476 t=2016-04-16T21:52:29+0000 lvl=info msg="Received 'terminated signal', exiting." t=2016-04-16T21:52:29+0000 lvl=info msg="Stopping REST API handler:" t=2016-04-16T21:52:29+0000 lvl=info msg=" - closing socket" socket=[::]:8443 t=2016-04-16T21:52:29+0000 lvl=info msg=" - skipping socket-activated socket" socket=/var/lib/lxd/unix.socket so it looks like it at least downloaded the image and then started the contianer. About 40 seconds after the container starts LXD gets restarted (which won't stop the container or anything), but it does make you wonder why it got restarted. If juju was connected at the time of the restart waiting for something, I can see why this would cause it to fail. Unfortunately, I don't think juju logs persist after a failed bootstrap. Was there something else running on the box that might cause LXD to restart while juju was bootstrapping? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1571082 Title: autopkgtest lxd provider tests fail for 2.0 To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1571082/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
