cloud-init generates ordering cycle via After=cloud-init in systemd-fsck
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Xenial |
Fix Released
|
High
|
Scott Moser | ||
Zesty |
Fix Released
|
High
|
Scott Moser | ||
Artful |
Fix Released
|
High
|
Unassigned |
Bug Description
http://
https:/
=== Begin SRU Template ===
[Impact]
Cloud-init's inclusion of a systemd drop-in file
/lib/
Caused a regression on systems that had entries in /etc/fstab
that were not authored by cloud-init (specifically that did not have
something like 'x-systemd.
filesystem options.
[Test Case]
The test can be done on any cloud that has space to put a non-root
filesystem.
a.) launch instance
b.) upgrade to cloud-init to -updates pocket
c.) create a filesystem and put it in /etc/fstab
bdev=
mkdir -p /mnt
mkfs.ext4 -F "$bdev"
echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab
reboot
d.) see mention of 'ordering cycle' in journal
$ journalctl -o short-precise | grep -i ordering.cycle
Sep 15 14:08:48.331033 xenial-
Sep 15 14:08:48.331097 xenial-
Sep 15 14:08:48.331108 xenial-
e.) upgrade to proposed
f.) reboot
g.) expect no mention of ordering cycle as seen in 'd'
$ journalctl -o short-precise | grep -i ordering.cycle || echo "no cycles"
no cycles
[Regression Potential]
This change will mean that bug 1691489 is present again.
That bug is much less severe and affects a much smaller set of users.
[Other Info]
Upstream commit at
https:/
=== End SRU Template ===
We're running several machines with
cloud-
without problems.
Just upgraded all machines to
cloud-
and rebooted them all.
All machines report ordering cycles in their dmesg, resulting in systemd breaking the
loop by NOT starting some important services, e.g. mouting local filesystems:
Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering cycle on networking.
Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found dependency on local-fs.
Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found dependency on home.mount/start
Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found dependency on systemd-
Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found dependency on cloud-init.
Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found dependency on networking.
Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking ordering cycle by deleting job local-fs.
Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job local-fs.
% cat /etc/fstab
LABEL=cloudimg-
LABEL=Home /home xfs defaults,logbufs=8 0 2
In this case /home isn't mounted as a result of systemd breaking the loop, resulting in services depending on /home not being started.
1. Tell us your cloud provider
AWS
2. dpkg-query -W -f='${Version}' cloud-init
0.7.9-233-
3. Any appropriate cloud-init configuration you can provide us
Nothing special - worked with 0.7.9-153-
The problem is this change:
diff -uaNr 153/lib/
--- 153/lib/
+++ 233/lib/
@@ -0,0 +1,2 @@
+[Unit]
+After=
WORKAROUND
==========
I just did a
rm /lib/systemd/
on all machines and rebooted them: no more dependency loops reported, everything works again.
Related bugs:
* bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks
* bug 1691489: fstab entries written by cloud-config may not be mounted
Related branches
- Scott Moser: Approve
-
Diff: 47 lines (+0/-12)3 files modifieddev/null (+0/-2)
packages/redhat/cloud-init.spec.in (+0/-6)
setup.py (+0/-4)
tags: | added: cycle ordering |
tags: |
added: systemd removed: cycle ordering |
Changed in cloud-init: | |
importance: | Undecided → High |
Changed in cloud-init: | |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu Zesty): | |
status: | New → Confirmed |
Changed in cloud-init (Ubuntu Xenial): | |
importance: | Undecided → High |
Changed in cloud-init (Ubuntu Zesty): | |
importance: | Undecided → High |
tags: | added: regression-released |
tags: |
added: regression-release removed: regression-released |
description: | updated |
Changed in cloud-init (Ubuntu Xenial): | |
status: | Confirmed → In Progress |
Changed in cloud-init (Ubuntu Zesty): | |
status: | Confirmed → In Progress |
Changed in cloud-init (Ubuntu Artful): | |
status: | Confirmed → In Progress |
Changed in cloud-init (Ubuntu Xenial): | |
assignee: | nobody → Scott Moser (smoser) |
Changed in cloud-init (Ubuntu Zesty): | |
assignee: | nobody → Scott Moser (smoser) |
I can reproduce this fairly easily with a standard ubuntu image.
a.) launch an instance on openstack (or somewhere with an additional disk)
upgrade cloud-init if necessary.
b.) create a filesystem and put it in /etc/fstab with simple options.
on my opensstack cloud-init sets up an entry like:
/dev/vdb /mnt auto defaults, nofail, x-systemd. requires= cloud-init. service, comment= cloudconfig 0 2
but what we want is just a simple line:
/dev/vdb /mnt auto defaults 0 2
c.) reboot
I'm attaching 'journal -o short-precise' output for first boot and after reboot (with the failure).