[Touch-packages] [Bug 1725351] Re: Systemd - Remote DOS of systemd-resolve service
Thanks Marc! Do you happen to know the answer to my other question? "I'm also not an expert on NSEC/DNSSEC. Is this something that any random app that uses DNS can be vulnerable too, or does it require a program to specifically be trying to invoke DNSSEC somehow?" -- 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/1725351 Title: Systemd - Remote DOS of systemd-resolve service Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: Hello, We would like to report a vulnerability about systemd which allows to DOS the systemd-resolve service. The vulnerability is described in the attached PDF file. Sincerely, Thomas IMBERT Sogeti ESEC R To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1725351/+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 1725351] Re: Systemd - Remote DOS of systemd-resolve service
@mdeslaur: Should I interpret the release of https://usn.ubuntu.com/usn/usn-3558-1/ as saying that the answer to my question in comment 19 is that yes, now we are getting the response? -- 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/1725351 Title: Systemd - Remote DOS of systemd-resolve service Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: Hello, We would like to report a vulnerability about systemd which allows to DOS the systemd-resolve service. The vulnerability is described in the attached PDF file. Sincerely, Thomas IMBERT Sogeti ESEC R To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1725351/+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 1732803] Re: systemd-journald RateLimitBurst is sometimes divided by 4
I got some advice on mistakes in my update to changelog. This version should be better. ** Patch added: "Second version with fixed changelog entries" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+attachment/5012529/+files/Fix-journald-rate-limit-with-low-disk-space.debdiff -- 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/1732803 Title: systemd-journald RateLimitBurst is sometimes divided by 4 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages This bug seems to date back to the original implementation of rate limiting (https://github.com/systemd/systemd/commit/6e409ce10d). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+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 1732803] Re: systemd-journald RateLimitBurst is sometimes divided by 4
This is my first attempt at a debdiff and an SRU. I'd love to know if I've filed it properly! -- 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/1732803 Title: systemd-journald RateLimitBurst is sometimes divided by 4 Status in systemd package in Ubuntu: New Bug description: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages This bug seems to date back to the original implementation of rate limiting (https://github.com/systemd/systemd/commit/6e409ce10d). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+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 1732803] Re: systemd-journald RateLimitBurst is sometimes divided by 4
Correction: I believe this occurs when the amount of remaining space until journald hits its allocated limit is between 1 and 16MB, not when the entire filesystem has that little space left. (This makes it much more likely to occur: any system that is using logs enough for them to be rotated due to space will hit this issue whenever it's near rotation time.) -- 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/1732803 Title: systemd-journald RateLimitBurst is sometimes divided by 4 Status in systemd package in Ubuntu: New Bug description: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages This bug seems to date back to the original implementation of rate limiting (https://github.com/systemd/systemd/commit/6e409ce10d). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+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 1732803] Re: systemd-journald RateLimitBurst is sometimes divided by 4
** Patch added: "debdiff backporting fix from upstream" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+attachment/5010237/+files/Fix-journald-rate-limit-with-low-disk-space.debdiff -- 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/1732803 Title: systemd-journald RateLimitBurst is sometimes divided by 4 Status in systemd package in Ubuntu: New Bug description: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages This bug seems to date back to the original implementation of rate limiting (https://github.com/systemd/systemd/commit/6e409ce10d). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732803/+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 1732803] [NEW] systemd-journald RateLimitBurst is sometimes divided by 4
Public bug reported: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description:Ubuntu 16.04.3 LTS Release:16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 Packages This bug seems to date back to the original implementation of rate limiting (https://github.com/systemd/systemd/commit/6e409ce10d). ** 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/1732803 Title: systemd-journald RateLimitBurst is sometimes divided by 4 Status in systemd package in Ubuntu: New Bug description: [Impact] systemd-journald allows you to configure a per-service journal rate limit in /etc/systemd/journald.conf via the RateLimitBurst parameter. systemd-journald has code that effectively increases the rate limit when there is a lot of disk space available. However, all versions of systemd before v232 had a bug which would shrink the rate limit when there is between 1 and 16 MB available on disk. If you designed a service to log at a rate R and configured RateLimitBurst to a little above R, this can lead to loss of logs when free disk is between 1 and 16 MB, as your service will be surprisingly rate limited at lower than your configured rate. This bug was fixed upstream in https://github.com/systemd/systemd/pull/4218 It is a straightforward one-line change that makes the code match the comments under it. [Test Case] Run a systemd service that prints lots of logs (eg `yes`). Fill your disk to have only 1MB full. Use journalctl to see how many log lines are between "Suppressed" lines. Note that it is 1/4 of what you'd expect. (Admittedly this test case is a little hard to achieve since journald itself is writing to disk. I did run into this in production.) [Regression Potential] This does mean that journald can write slightly more to disk than it did before when free disk is between 1 and 16MB, but given that the full burst rate is available below 1MB it seems unlikely that any systems are depending on this change in order to not break. The fix has been in systemd since v232 (shipped in Zesty). I would like to see it in Xenial. [Other Info] I am seeing this on: ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 1 ~/systemd-229$ lsb_release -rd Description: Ubuntu 16.04.3 LTS Release: 16.04 ubuntu@ip-10-0-2-135[i-0b196ce4b8dc3fc55] 0 ~/systemd-229$ apt-cache policy systemd systemd: Installed: 229-4ubuntu19 Candidate: 229-4ubuntu21 Version table: 229-4ubuntu21 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 229-4ubuntu19 100 100 /var/lib/dpkg/status
[Touch-packages] [Bug 1725351] Re: Systemd - Remote DOS of systemd-resolve service
We manually enable systemd-resolved.service on xenial. It's installed though it is not the default. Does that mean we are not going to get the fix for this? I'm also not an expert on NSEC/DNSSEC. Is this something that any random app that uses DNS can be vulnerable too, or does it require a program to specifically be trying to invoke DNSSEC somehow? -- 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/1725351 Title: Systemd - Remote DOS of systemd-resolve service Status in systemd package in Ubuntu: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: In Progress Bug description: Hello, We would like to report a vulnerability about systemd which allows to DOS the systemd-resolve service. The vulnerability is described in the attached PDF file. Sincerely, Thomas IMBERT Sogeti ESEC R To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1725351/+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 1719851] Re: ca-certificates isn't updated in LTS 16.04
I just saw this via the USN. I'm having trouble evaluating the urgency of this fix. Is the issue: - Without this, connecting to some sites will fail because of missing/lapsed CAs or - Without this, you'll probably get MITMed because you're trusting some insecure hacked CAs ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1719851 Title: ca-certificates isn't updated in LTS 16.04 Status in ca-certificates package in Ubuntu: Fix Released Status in ca-certificates source package in Trusty: Fix Released Status in ca-certificates source package in Xenial: Fix Released Status in ca-certificates source package in Zesty: Fix Released Status in ca-certificates source package in Artful: Fix Released Bug description: ca-certificates should contain root certificates for new CA from Amazon They are added in version 20170717, The Artful Aardvark (pre-release freeze) But that isn't reflected neither in zesty, nor backports or security We recently got a letter from Amazon to update our SSL certs till October 25. Would be extremely great if ca-certificates will be updated via unattended upgrades in-time. Marking as security, because several CAs were removed (compromised?). Or maybe there is a reason, why root cert list isn't updated on LTS releases? ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: ca-certificates 20161130 ProcVersionSignature: User Name 4.10.0-21.23-generic 4.10.11 Uname: Linux 4.10.0-21-generic x86_64 ApportVersion: 2.20.4-0ubuntu4.5 Architecture: amd64 Date: Wed Sep 27 11:10:01 2017 Ec2AMI: ami-6edd3078 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1d Ec2InstanceType: m3.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable PackageArchitecture: all SourcePackage: ca-certificates UpgradeStatus: Upgraded to zesty on 2017-05-19 (131 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1719851/+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 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)
Hi. This issue affected us on Xenial; we explicitly enable systemd-
networkd on our images (when creating our AMI), and after a recent AMI
rebuild we were no longer able to start our AMIs. When I looked at the
system console we saw things that looked like:
[ 52.866176] cloud-init[721]: Cloud-init v. 0.7.8 running 'init' at Wed, 30
Nov 2016 03:13:22 +. Up 51.74 seconds.
[ 52.873058] cloud-init[721]: ci-info: +++Net device
info
[ 52.879734] cloud-init[721]: ci-info:
++---+---+---+---+---+
[ 52.886030] cloud-init[721]: ci-info: | Device | Up | Address |Mask
| Scope | Hw-Address|
[ 52.892162] cloud-init[721]: ci-info:
++---+---+---+---+---+
[ 52.897909] cloud-init[721]: ci-info: | lo | True | 127.0.0.1 |
255.0.0.0 | . | . |
[ 52.904408] cloud-init[721]: ci-info: | lo | True | ::1/128 | .
| host | . |
[ 52.910315] cloud-init[721]: ci-info: | ens3 | False | . | .
| . | 0a:c6:90:b1:76:26 |
[ 52.916070] cloud-init[721]: ci-info:
++---+---+---+---+---+
[ 52.921096] cloud-init[721]: 2016-11-30 03:13:23,567 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]:
request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries
exceeded with url: /2009-04-04/meta-data/instance-id (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno 101] Network
is unreachable',))]
I eventually noticed that (in comparison to the system log for an older
working AMI) the "Starting Network Service" line was missing and found
this bug. (Text above included mostly in case anybody else sees the
same issue and searches for the error.)
I tested with xenial-proposed and 229-4ubuntu13, and it fixed the issue.
I'd love to see this fix in stable xenial soon!
--
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/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
Status in systemd:
Fix Released
Status in cloud-init package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Fix Committed
Status in cloud-init source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Fix Committed
Status in cloud-init source package in Yakkety:
New
Status in systemd source package in Yakkety:
Fix Committed
Bug description:
Ubuntu Core 16 images using cloud-init fail to function when the
DataSource is over the network (Like OpenStack) as networking is not
yet available when cloud-init.service runs.
cloud-init service unit deps look like this:
[Unit]
Description=Initial cloud-init job (metadata service crawler)
DefaultDependencies=no
Wants=cloud-init-local.service
Wants=local-fs.target
Wants=sshd-keygen.service
Wants=sshd.service
After=cloud-init-local.service
After=networking.service
Requires=networking.service
Before=basic.target
Before=dbus.socket
Before=network-online.target
Before=sshd-keygen.service
Before=sshd.service
Before=systemd-user-sessions.service
Conflicts=shutdown.target
Here's networkd unit deps:
[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
# dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
# dropped once tuntap is moved to netlink
After=systemd-udevd.service dbus.service network-pre.target
systemd-sysusers.service systemd-sysctl.service
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target
# On kdbus systems we pull in the busname explicitly, because it
# carries policy that allows the daemon to acquire its name.
Wants=org.freedesktop.network1.busname
After=org.freedesktop.network1.busname
And a critical-chain output:
root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
Failed to get ID: Unit name systemd-networkd is not valid.
The time after the unit is active or started is printed after the "@"
character.
The time the unit takes to start is printed after the "+" character.
root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
The time after the unit is active or started is printed after the "@"
character.
The time the unit takes to start is printed after the "+" character.
systemd-networkd.service +440ms
└─dbus.service @11.461s
└─basic.target @11.403s
└─sockets.target @11.401s
└─dbus.socket @11.398s
└─cloud-init.service @10.127s +1.266s
└─networking.service @9.305s +799ms
