This is fixed in cloud-init 0.7.9.
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
What is the recommended way to have an application systemd service run
after cloud-final.service ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623868
Title:
cloud-final.service does not run due
This bug was fixed in the package cloud-init -
0.7.8-1-g3705bb5-0ubuntu1~16.04.1
---
cloud-init (0.7.8-1-g3705bb5-0ubuntu1~16.04.1) xenial-proposed; urgency=medium
* New upstream release 0.7.8.
* New upstream snapshot.
- systemd: put cloud-init.target After multi-user.target
verified with xenial-proposed and 0.7.8-1-g3705bb5-0ubuntu1~16.04.1 as
described in bug.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This bug was fixed in the package cloud-init - 0.7.8-1-g3705bb5-0ubuntu1
---
cloud-init (0.7.8-1-g3705bb5-0ubuntu1) yakkety; urgency=medium
* New upstream release 0.7.8.
* New upstream snapshot.
- systemd: put cloud-init.target After multi-user.target (LP: #1623868)
--
** Description changed:
- With current yakkety cloud images (at least in Scalingstack), I often
- run into this dependency cycle at boot:
+ Begin SRU Template
+ [Impact]
+ As part of the change in bug 1623868, we made cloud-final.target
+ run After multi-user.target. That created a
Hello Martin, or anyone else affected,
Accepted cloud-init into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.8-1-g3705bb5-0ubuntu1~16.04.1 in a few hours, and then in the
-proposed repository.
Please help us by testing this
Just for ease of reading:
== deleting job cloud-init.target ==
Sep 15 12:59:32 ubuntu systemd[1]: multi-user.target: Found ordering cycle on
multi-user.target/start
Sep 15 12:59:32 ubuntu systemd[1]: multi-user.target: Found dependency on
cloud-init.target/start
Sep 15 12:59:32 ubuntu
** Attachment added: "journalctl of vm where cloud-init.target was deleted"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1623868/+attachment/4741408/+files/journalctl-break-cloud-init-target.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
** Attachment added: "journalctl of vm where cloud-final was deleted"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1623868/+attachment/4741407/+files/journalctl-break-cloud-final.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
For completeness, I've attached journalctl of 2 vms.
Both are the same yakkety image, launched with no user-data within seconds of
each other.
In one, systemd decided to:
Sep 15 12:59:34 ubuntu systemd[1]: cloud-init.target: Breaking ordering
cycle by deleting job cloud-final.service/start
Running into the same since today.
Seems alto reproducible with uvtool.
uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu yakkety-test-not-
finalizing-cloud-init release=yakkety arch=amd64 label=daily
I see the final stage completing in the log:
journalctl | grep "final: SUCCESS"
Sep 15
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623868
Title:
Most of the time (at least in LXD, timing issue) cloud-init.target is
inactive instead, which is also unintended. This is because it is
installed into multi-user.target and thus gets an implied Before=multi-
user.target as well. With explicitly adding After=multi-user.target
(since one part of it,
14 matches
Mail list logo
