[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition
I haven't been able to reproduce this again, so marking as invalid.
Thanks for all your help previously, Martin.
** Changed in: systemd (Ubuntu)
Status: Incomplete => Invalid
** Changed in: juju-core
Status: Confirmed => Invalid
--
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:
Invalid
Status in systemd package in Ubuntu:
Invalid
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 +. Up 182 seconds.
[ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct
2015 00:29:03 +. 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1492088] Re: juju bootstrap fails inside a wily container
Juju will issue a systemctl link to link the unit files, then run
systemctl enable. I cannot recreate this issue on wily, either as a
host, or a wily container running on a wily host (with or without KVM
enabled).
Martin - what information could Adam gather to help debug the issue?
--
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/1492088
Title:
juju bootstrap fails inside a wily container
Status in juju-core:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
Running juju 1.24.5 and attempting to do a local bootstrap inside a
wily container fails with the following:
[DEBUG: 09-03 20:49:56, container.py:139] Error with command: [Output]
'2015-09-03 20:49:35 INFO juju.cmd supercommand.go:37 running juju
[1.24.5-wily-amd64 gc]
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:109 Made
dir /home/ubuntu/.cloud-install/juju/environments
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking state port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking API port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:38
opening environment "local"
2015-09-03 20:49:35 DEBUG juju.container.kvm kvm.go:71 kvm-ok output:
INFO: /dev/kvm exists
KVM acceleration can be used
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:308
writing jenv file
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:432
writing jenv file to /home/ubuntu/.cloud-
install/juju/environments/local.jenv
2015-09-03 20:49:35 INFO juju.network network.go:194 setting prefer-
ipv6 to false
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Bootstrapping environment
"local"
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:98
environment "local" supports service/machine networks: false
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:100
network management by juju enabled: true
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Starting new instance for
initial state server
2015-09-03 20:49:35 INFO juju.environs.bootstrap bootstrap.go:184
newest version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.environs.bootstrap bootstrap.go:212
picked bootstrap tools version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.cmd cmd.go:113 Building tools to upload
(1.24.5.1-wily-amd64)
2015-09-03 20:49:36 DEBUG juju.environs.sync sync.go:304 Building
tools
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:122 looking
for: juju
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:161 checking:
/usr/bin/jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:167 found
existing jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:177 target: /tmp
/juju-tools782467678/jujud
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:232 forcing
version to 1.24.5.1
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: &tar.Header{Name:"FORCE-VERSION", Mode:436, Uid:0, Gid:0,
Size:8, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: &tar.Header{Name:"jujud", Mode:493, Uid:0, Gid:0,
Size:67623560, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:42 INFO juju.environs.sync sync.go:323 built tools
1.24.5.1-wily-amd64 (13769kB)
2015-09-03 20:49:42 INFO juju.cmd cmd.go:113 Installing Juju agent on
bootstrap instance
2015-09-03 20:49:42 DEBUG juju.cloudconfig.instancecfg
instancecfg.go:521 Setting numa ctl preference to false
2015-09-03 20:49:42 INFO juju.provider.local environ.go:156 local
provider; disabling refreshing OS updates.
2015-09-03 20:49:42 INFO juju.provider.local environ.go:162 local
provider; disabling OS upgrades.
Logging to /home/ubuntu/.cloud-install/juju/local/cloud-init-
output.log on remote host
Installing package: curl
Installing package: cpu-checker
Installing pa
[Touch-packages] [Bug 1492088] Re: juju bootstrap fails inside a wily container
Opening up a systemd record so that team can take a look.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
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/1492088
Title:
juju bootstrap fails inside a wily container
Status in juju-core:
Triaged
Status in systemd package in Ubuntu:
New
Bug description:
Running juju 1.24.5 and attempting to do a local bootstrap inside a
wily container fails with the following:
[DEBUG: 09-03 20:49:56, container.py:139] Error with command: [Output]
'2015-09-03 20:49:35 INFO juju.cmd supercommand.go:37 running juju
[1.24.5-wily-amd64 gc]
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:109 Made
dir /home/ubuntu/.cloud-install/juju/environments
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking state port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:245
checking API port
2015-09-03 20:49:35 INFO juju.provider.local environprovider.go:38
opening environment "local"
2015-09-03 20:49:35 DEBUG juju.container.kvm kvm.go:71 kvm-ok output:
INFO: /dev/kvm exists
KVM acceleration can be used
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:308
writing jenv file
2015-09-03 20:49:35 DEBUG juju.environs.configstore disk.go:432
writing jenv file to /home/ubuntu/.cloud-
install/juju/environments/local.jenv
2015-09-03 20:49:35 INFO juju.network network.go:194 setting prefer-
ipv6 to false
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Bootstrapping environment
"local"
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:98
environment "local" supports service/machine networks: false
2015-09-03 20:49:35 DEBUG juju.environs.bootstrap bootstrap.go:100
network management by juju enabled: true
2015-09-03 20:49:35 DEBUG juju.provider.local environ.go:325 found
"10.0.6.1" as address for "lxcbr0"
2015-09-03 20:49:35 INFO juju.cmd cmd.go:113 Starting new instance for
initial state server
2015-09-03 20:49:35 INFO juju.environs.bootstrap bootstrap.go:184
newest version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.environs.bootstrap bootstrap.go:212
picked bootstrap tools version: 1.24.5.1
2015-09-03 20:49:36 INFO juju.cmd cmd.go:113 Building tools to upload
(1.24.5.1-wily-amd64)
2015-09-03 20:49:36 DEBUG juju.environs.sync sync.go:304 Building
tools
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:122 looking
for: juju
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:161 checking:
/usr/bin/jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:167 found
existing jujud
2015-09-03 20:49:36 INFO juju.environs.tools build.go:177 target: /tmp
/juju-tools782467678/jujud
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:232 forcing
version to 1.24.5.1
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: &tar.Header{Name:"FORCE-VERSION", Mode:436, Uid:0, Gid:0,
Size:8, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:36 DEBUG juju.environs.tools build.go:38 adding
entry: &tar.Header{Name:"jujud", Mode:493, Uid:0, Gid:0,
Size:67623560, ModTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Typeflag:0x30, Linkname:"",
Uname:"ubuntu", Gname:"ubuntu", Devmajor:0, Devminor:0,
AccessTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)},
ChangeTime:time.Time{sec:63576910176, nsec:90190527,
loc:(*time.Location)(0x2c9b140)}, Xattrs:map[string]string(nil)}
2015-09-03 20:49:42 INFO juju.environs.sync sync.go:323 built tools
1.24.5.1-wily-amd64 (13769kB)
2015-09-03 20:49:42 INFO juju.cmd cmd.go:113 Installing Juju agent on
bootstrap instance
2015-09-03 20:49:42 DEBUG juju.cloudconfig.instancecfg
instancecfg.go:521 Setting numa ctl preference to false
2015-09-03 20:49:42 INFO juju.provider.local environ.go:156 local
provider; disabling refreshing OS updates.
2015-09-03 20:49:42 INFO juju.provider.local environ.go:162 local
provider; disabling OS upgrades.
Logging to /home/ubuntu/.cloud-install/juju/local/cloud-init-
output.log on remote host
Installing package: curl
Installing package: cpu-checker
Installing package: bridge-utils
Installing package: rsyslog-gnutls
Installing package: cloud-utils
Installing package: cloud-image-utils
Installing package
[Touch-packages] [Bug 1514623] Re: New upstream bugfix release 1.0.8 (LXC MRE)
Bug #1515463 reveals that this change broke Juju. Marking as verification failed. ** Tags removed: verification-needed ** Tags added: verification-failed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1514623 Title: New upstream bugfix release 1.0.8 (LXC MRE) Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Trusty: Fix Committed Bug description: We have released LXC 1.0.7 upstream: https://linuxcontainers.org/lxc/news This will be the eigth upstream bugfix release to hit trusty. The upstream changes are detailed at the URL above. The MRE was reviewed by Martin Pitt here: https://lists.ubuntu.com/archives/technical- board/2014-April/001869.html As for testing, this version went through both automated testing (all the tests present in lxc-tests + the python3 API tests) as well as manual testing done by myself, LXC contributors and LXC users who've been building the git stable branch for a while now. Xenial is now on LXC 1.1.5 (and 1.1.5 will hit vivid and wily as SRU) which bugfixes for 1.0.8 have been taken from. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1514623/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition
** Tags removed: bug-squad
--
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 +. Up 182 seconds.
[ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct
2015 00:29:03 +. 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 +. Up 182 seconds.
[ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct
2015 00:29:03 +. 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition
** Changed in: juju-core Importance: Critical => High -- 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition
** Changed in: juju-core Assignee: (unassigned) => Cheryl Jennings (cherylj) -- 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily, juju-template-restart.service race condition
Thanks for digging into this so much, Martin! 1 - Yes, I will try the runcmd you mention and see if it works. 2 - However, I thought adding in After=cloud-config.target would ensure that it wouldn't start until after cloud-init completes? 3 - The recreate steps for this are: - Bootstrap local env on wily (this won't create a container) - Deploy using the command: `juju deploy wily/ubuntu`. It may take some time before you see the container started as juju will download the image before starting the template container. -- 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1510619] Re: Wily: add machine fails using kvm and lxcbr0
** Also affects: lxc (Ubuntu) Importance: Undecided Status: New ** Changed in: juju-core Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1510619 Title: Wily: add machine fails using kvm and lxcbr0 Status in juju-core: Invalid Status in lxc package in Ubuntu: New Bug description: Juju fails to start a machine after add-machine takes place. My environments.yaml: local: type: local container: kvm network-bridge: lxcbr0 Status output: ubuntu@ancient-spot:~$ juju status environment: local machines: "0": agent-state: started agent-version: 1.24.7.1 dns-name: localhost instance-id: localhost series: wily state-server-member-status: has-vote "1": agent-state: pending instance-id: ubuntu-local-machine-1 series: wily hardware: arch=amd64 cpu-cores=1 mem=512M root-disk=8192M debug log: http://paste.ubuntu.com/12980615/ I never see anything in the logs which indicate machine-1 is being deployed or what else could be going on with it. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1510619/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
Is there anything else needed from the container? I'm going to mark this back to new as I've uploaded the requested information. ** Changed in: systemd (Ubuntu) Status: Incomplete => New -- 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 Status in juju-core: Invalid Status in systemd package in Ubuntu: New 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
** Attachment added: "update-utmp.trace" https://bugs.launchpad.net/juju-core/+bug/1509747/+attachment/4505694/+files/update-utmp.trace -- 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 Status in juju-core: Invalid 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
root@juju-wily-lxc-template:/# systemctl daemon-reload root@juju-wily-lxc-template:/# systemctl restart systemd-update-utmp-runlevel Job for systemd-update-utmp-runlevel.service failed because the control process exited with error code. See "systemctl status systemd-update-utmp-runlevel.service" and "journalctl -xe" for details. 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 Mon 2015-10-26 14:06:01 UTC; 19s ago Docs: man:systemd-update-utmp.service(8) man:utmp(5) Process: 7043 ExecStart=/usr/bin/strace -fvvs1024 -o /run/update-utmp.trace /lib/systemd/systemd-update-utmp runlevel (code=exited, status=1/FAILURE) Main PID: 7043 (code=exited, status=1/FAILURE) ** Attachment added: "debug-journalctl" https://bugs.launchpad.net/juju-core/+bug/1509747/+attachment/4505642/+files/debug-journalctl -- 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 Status in juju-core: Invalid 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
** Attachment added: "user-data.txt" https://bugs.launchpad.net/juju-core/+bug/1509747/+attachment/4505640/+files/user-data.txt -- 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 Status in juju-core: Invalid 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
** Attachment added: "journalctl" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1509747/+attachment/4505077/+files/journalctl -- 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 Status in juju-core: Invalid Status in systemd package in Ubuntu: New 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
I see many failures in journalctl of this type: systemd[1]: Failed to reset devices.list on /lxc/juju-wily-lxc- template/system.slice/systemd-update-utmp.service: Permission denied -- 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 Status in juju-core: Invalid Status in systemd package in Ubuntu: New 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509747] Re: Intermittent lxc failures on wily
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: juju-core Status: New => Invalid -- 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 Status in juju-core: Invalid Status in systemd package in Ubuntu: New 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 +. Up 182 seconds. [ 2300.886101] cloud-init[2758]: Cloud-init v. 0.7.7 finished at Sun, 25 Oct 2015 00:29:03 +. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509414] Re: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers
Serge - your changes from comment #22 will break juju with lxc. juju will need to be modified to call systemctl add-wants multi-user.target lxc.service -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1509414 Title: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers Status in lxc package in Ubuntu: Confirmed Bug description: [Problem] The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes: It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point. This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390). The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host. [Test Case] 1.) Verify expectation for each image - -disk1.img cloud image, check for file - -root.tar.xz image (used by lxd) and check for file - -root.tar.gz image (used by lxc) For each of those images, verify: a.) A cloud image should not have /etc/default/lxc-net b.) lxd should be installed (dpkg-query --show | grep lxd) 2.) Start instance from updated image and start instance in lxc inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily # wait until lxc-ls --fancy shows 'running' lxc-attach -n bugcheck wget http://ubuntu.com 3.) Start instance from updated image and start instance in lxd inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxd import-images ubuntu wily lxc launch ubuntu # wait some amount lxc attach bugcheck wget http://ubuntu.com [Regression Potentional] The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service. [Other Info] Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services. We are moving that logic to happen the first time that 'lxc-net' service starts. This means first boot for a cloud instance rather than cloud-image build time. [Work around] To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0. sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net && sudo service lxc-net stop && sudo service lxc-net start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509414] Re: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers
Verified that Juju can start lxc containers with the proposed changes. The containers came up and were able to communicate with the state server, even when on a separate machine. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1509414 Title: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers Status in lxc package in Ubuntu: Confirmed Bug description: [Problem] The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes: It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point. This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390). The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host. [Test Case] 1.) Verify expectation for each image - -disk1.img cloud image, check for file - -root.tar.xz image (used by lxd) and check for file - -root.tar.gz image (used by lxc) For each of those images, verify: a.) A cloud image should not have /etc/default/lxc-net b.) lxd should be installed (dpkg-query --show | grep lxd) 2.) Start instance from updated image and start instance in lxc inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily # wait until lxc-ls --fancy shows 'running' lxc-attach -n bugcheck wget http://ubuntu.com 3.) Start instance from updated image and start instance in lxd inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxd import-images ubuntu wily lxc launch ubuntu # wait some amount lxc attach bugcheck wget http://ubuntu.com [Regression Potentional] The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service. [Other Info] Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services. We are moving that logic to happen the first time that 'lxc-net' service starts. This means first boot for a cloud instance rather than cloud-image build time. [Work around] To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0. sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net && sudo service lxc-net stop && sudo service lxc-net start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1509414] Re: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers
Kicked off instances for testing with Juju. Will update with results once my testing is complete. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1509414 Title: pre-installed lxc in cloud image produces broken lxc (and later lxd) containers Status in lxc package in Ubuntu: Confirmed Bug description: [Problem] The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes: It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point. This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390). The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host. [Test Case] 1.) Verify expectation for each image - -disk1.img cloud image, check for file - -root.tar.xz image (used by lxd) and check for file - -root.tar.gz image (used by lxc) For each of those images, verify: a.) A cloud image should not have /etc/default/lxc-net b.) lxd should be installed (dpkg-query --show | grep lxd) 2.) Start instance from updated image and start instance in lxc inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily # wait until lxc-ls --fancy shows 'running' lxc-attach -n bugcheck wget http://ubuntu.com 3.) Start instance from updated image and start instance in lxd inside launch instance on openstack or kvm or other verify lxcbr0 bridge exists lxd import-images ubuntu wily lxc launch ubuntu # wait some amount lxc attach bugcheck wget http://ubuntu.com [Regression Potentional] The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service. [Other Info] Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services. We are moving that logic to happen the first time that 'lxc-net' service starts. This means first boot for a cloud instance rather than cloud-image build time. [Work around] To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0. sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net && sudo service lxc-net stop && sudo service lxc-net start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1480310] Re: dbus link request failed for service FOO: Unit name FOO is not valid.
This appears to be a regression in systemd. I extracted the unit file we're trying to link and manually linked it through systemctl and it succeeded with 222-2ubuntu1, but failed with 223-1ubuntu1: ubuntu@cherylj-wily4:~$ apt-cache policy systemd systemd: Installed: 222-2ubuntu1 Candidate: 223-1ubuntu1 Version table: 223-1ubuntu1 0 500 http://nova.clouds.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages *** 222-2ubuntu1 0 100 /var/lib/dpkg/status root@cherylj-wily4:~$ sudo systemctl link /var/lib/juju/init/juju-db-ubuntu-local/juju-db-ubuntu-local.service Created symlink from /etc/systemd/system/juju-db-ubuntu-local.service to /var/lib/juju/init/juju-db-ubuntu-local/juju-db-ubuntu-local.service. ubuntu@cherylj-wily4:~$ sudo systemctl disable /var/lib/juju/init/juju-db-ubuntu-local/juju-db-ubuntu-local.service Removed symlink /etc/systemd/system/juju-db-ubuntu-local.service. ubuntu@cherylj-wily4:~$ sudo apt-get upgrade ... ubuntu@cherylj-wily4:~$ apt-cache policy systemd systemd: Installed: 223-1ubuntu1 Candidate: 223-1ubuntu1 Version table: *** 223-1ubuntu1 0 500 http://nova.clouds.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status ubuntu@cherylj-wily4:~$ sudo systemctl link /var/lib/juju/init/juju-db-ubuntu-local/juju-db-ubuntu-local.service Failed to execute operation: Unit name /var/lib/juju/init/juju-db-ubuntu-local/juju-db-ubuntu-local.service is not valid. -- 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/1480310 Title: dbus link request failed for service FOO: Unit name FOO is not valid. Status in juju-core: Triaged Status in systemd package in Ubuntu: New Bug description: As seen in http://reports.vapour.ws/releases/2936/job/local-deploy-wily-amd64/attempt/136 Juju cannot bootstrap on wily because ERROR juju.service.systemd service.go:149 dbus link request failed for service "juju-db-jenkins-local-deploy-wily-amd64": Unit name /var/lib/juju/init/juju-db-jenkins-local-deploy-wily-amd64/juju-db-jenkins-local-deploy-wily-amd64.service is not valid. This error first occurred after the wily-slave got package updates. The released jujus get the same errors as the jujus under test. This issue is probably an Ubuntu packaging break. I am making the test non-voting since we can see table 1.24.3 no longer works. To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1480310/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
