← Back to team overview

touch-packages team mailing list archive

[Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition

 

I was working on implementing your suggested changes yesterday, but
could not get a recreate on ec2 without the changes as a baseline.  I
tried multiple instance types, thinking that would help trigger the
hang, but to no avail :(

I hit this a lot using canonistack and will try to recreate there again.

The recreate steps look good.  Thanks for adding them, and for your
explanation about using the cloud-config target.

I've asked around to see if others can recreate on their local wily
systems, and it seems I'm the only one who has run into this.  I'm going
to lower the priority and continue to try and get a recreate.

** Changed in: juju-core
   Importance: High => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1509747

Title:
  Intermittent lxc failures on wily, juju-template-restart.service race
  condition

Status in juju-core:
  Confirmed
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Frequently, when creating an lxc container on wily (either through
  --to lxc:#, or using the local provider on wily), the template never
  stops and errors out here:

  [ 2300.885573] cloud-init[2758]: Cloud-init v. 0.7.7 running 'modules:final' at Sun, 25 Oct 2015 00:28:57 +0000. Up 182 seconds.
  [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +0000. Datasource DataSourceNoCloudNet [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net].  Up 189 seconds
  [  OK  ] Started Execute cloud user/final scripts.
  [  OK  ] Reached target Multi-User System.
  [  OK  ] Reached target Graphical Interface.
           Starting Update UTMP about System Runlevel Changes...
  [  OK  ] Started /dev/initctl Compatibility Daemon.
  [FAILED] Failed to start Update UTMP about System Runlevel Changes.
  See 'systemctl status systemd-update-utmp-runlevel.service' for details.

  Attaching to the container and running the above command yields:

  ubuntu@cherylj-wily-local-lxc:~$ sudo lxc-attach --name juju-wily-lxc-template
  root@juju-wily-lxc-template:~# systemctl status systemd-update-utmp-runlevel.service
  ● systemd-update-utmp-runlevel.service - Update UTMP about System Runlevel Changes
     Loaded: loaded (/lib/systemd/system/systemd-update-utmp-runlevel.service; static; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2015-10-25 00:30:29 UTC; 2h 23min ago
       Docs: man:systemd-update-utmp.service(8)
             man:utmp(5)
    Process: 3963 ExecStart=/lib/systemd/systemd-update-utmp runlevel (code=exited, status=1/FAILURE)
   Main PID: 3963 (code=exited, status=1/FAILURE)

  Oct 25 00:29:46 juju-wily-lxc-template systemd[1]: Starting Update UTMP about System Runlevel Changes...
  Oct 25 00:30:29 juju-wily-lxc-template systemd[1]: systemd-update-utmp-runlevel.service: Main process exited, code=exited, status=1/FAILURE
  Oct 25 00:30:30 juju-wily-lxc-template systemd[1]: Failed to start Update UTMP about System Runlevel Changes.
  Oct 25 00:30:30 juju-wily-lxc-template systemd[1]: systemd-update-utmp-runlevel.service: Unit entered failed state.
  Oct 25 00:30:30 juju-wily-lxc-template systemd[1]: systemd-update-utmp-runlevel.service: Failed with result 'exit-code'.

  I have seen this on ec2 and in canonistack.  The canonistack machine
  is available for further debugging.  Ping me for access.

  Reproducer from a clean wily cloud image
  ----------------------------------------
  sudo apt install -y juju-local
  juju init
  sed -i '/default-series/ { s/# //; s/trusty/wily/ }' .juju/environments.yaml
  juju bootstrap
  juju deploy wily/ubuntu

  iterate with
  juju destroy-service ubuntu
  juju destroy-machine 1
  sudo lxc-destroy -n juju-wily-lxc-template
  → then you can re-run "deploy".

  At some point this should hang on the creation of juju-wily-lxc-template, i. e. that container never stops.
  (Note: Martin Pitt could not reproduce this yet with these steps)

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions