Re: [Sts-sponsors] Please review and sponsor LP1968805 ec2-hibinit-agent for Amazon AWS
Hi everyone, AWS EC2 engineering teams have reviewed the patch, and have merged the commit to upstream now. https://github.com/aws/amazon-ec2-hibinit-agent/pull/22 commit a2303d269610a6e7415c5045766da605eaa7e30f From: Matthew Ruffell Date: Wed, 20 Apr 2022 15:59:25 +1200 Subject: Swapon with maximum priority before hibernation Link: https://github.com/aws/amazon-ec2-hibinit-agent/commit/a2303d269610a6e7415c5045766da605eaa7e30f I have uploaded fresh debdiffs to the launchpad bug to account for minor version changes due to kinetic being the newest development release, and added the correct forwarded tag. Can you please review and sponsor the changes? Thanks, Matthew On Thu, Apr 28, 2022 at 3:35 AM Mauricio Faria de Oliveira wrote: > > Hey Matthew, > > Sorry for the delay in getting to this. My own opinion below: > > Yes, I believe that having positive reviews and QA from upstream would be > ideal, > and since upstream is AWS themselves, it'd seem to fit a WoCustomer status > (although admittedly this is the first time I see this scenario :-) > > cheers, > > On Wed, Apr 27, 2022 at 2:52 AM Matthew Ruffell > wrote: > > > > Upstream has responded that they have seen the pull request, and they are > > going > > to assign it to one of their engineers to review: > > > > > Thanks for reporting and putting together a patch - the engineering team > > > in > > > EC2 that maintains the agent is aware of the patch and are prioritizing > > > testing it. I'll ask them to give you an ETA when they have one. > > > > https://github.com/aws/amazon-ec2-hibinit-agent/issues/20#issuecomment-1104679221 > > > > Do you want to wait until we get a positive review from upstream? I suppose > > we > > can tell AWS that the case can be WoCus while we are waiting for upstream to > > review, and it will pause the SLA timer. > > > > On Thu, Apr 21, 2022 at 5:54 PM Matthew Ruffell > > wrote: > > > > > > Hi everyone, > > > > > > Could you please review LP #1968805 [1], and sponsor the uploads if it > > > looks > > > okay? > > > > > > [1] > > > https://bugs.launchpad.net/ubuntu/+source/ec2-hibinit-agent/+bug/1968805 > > > > > > I think bumping the priority to 32767 is the best solution for this > > > particular > > > case, since it would be higher than priorities users would be using in > > > the wild, > > > if they happen to have multiple swapfiles configured. > > > > > > I have submitted the patches upstream, but no word back. The upstream is > > > AWS > > > though, so maybe I might be able to put the SLA on hold for feedback > > > there, > > > but otherwise, we have about one month left on the SLA to get this fixed, > > > so > > > I wasn't going to wait. > > > > > > I did ask the CPC team about their feelings on the patches, but I didn't > > > get > > > much of a response other than from Chris Newcomer in the CPC channel. > > > > > > If you were going to test this for yourself, best stick with Focal for the > > > moment, as Jammy is broken on xen instance types, and is being tracked > > > separately in > > > https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1968062 > > > > > > Let me know if you have any feedback, or think this should be fixed in a > > > different way. > > > > > > And yes, Dan, this is probably a duplicate of > > > https://bugs.launchpad.net/bugs/1910252 > > > where the real root cause is that systemd blindly hibernates to the > > > highest > > > priority swapfile, as it has no way to know what resume device and offset > > > the > > > kernel is configured to resume from. SRUing such a change might be > > > difficult > > > as those who accept the standard behaviour would have to manually update > > > their > > > configuration on their systems to tell systemd what swapfile to hibernate > > > to. > > > > > > I think talking with upstream systemd will go past the 1 month left on > > > the SLA, > > > and so these straightforward patches to ec2-hibinit-agent are probably > > > the best > > > low risk way to work around the bug, and fix AWS users. > > > > > > PS, our ec2-hibinit-agent package diverged from upstream long ago, and the > > > foundations team appear to be happy carrying patches not upstreamed. > > > > > > Thanks, > > > Matthew > > > > -- > > Mailing list: https://launchpad.net/~sts-sponsors > > Post to : sts-sponsors@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~sts-sponsors > > More help : https://help.launchpad.net/ListHelp > > > > -- > Mauricio Faria de Oliveira -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Hey Fabio,
That happens when the package lands in -proposed.
It looks like the SRU vanguards this Wed/Thu are Robie/Lukasz,
which is good as they are familiar with the discussion/changes,
so I'll ask if they have SRU review cycles to for this upload.
Thanks for following up!
** Changed in: klibc (Ubuntu Bionic)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
Confirmed
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is
a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive
DHCP offers after their specified timeout (but within the 10-second error
timeout). However, 1) that is buggy behaviour and should be exposed. Such a
user would need to update their specified timeout to make it long enough to
receive the DHCP offer (setting the timeout to 10 would keep the existing
behaviour). 2) I think it is unlikely that such a scenario exists at all. The
10-second timeout problem happens when there are problems with the interface
that prevent it from even sending out the DHCP request. I think it is very
unlikely (or even, impossible) that DHCP offers would be received on a dead
interface.
Based on the above points, I consider the regression
[Sts-sponsors] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Should this bug be changed to Fix Committed at this point?
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
Incomplete
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
[ Regression potential ]
This change ensures that user-specified timeouts are never exceeded, which is
a problem that appears to happen only in case of interface errors.
It may be that someone is relying on current behaviour where they receive
DHCP offers after their specified timeout (but within the 10-second error
timeout). However, 1) that is buggy behaviour and should be exposed. Such a
user would need to update their specified timeout to make it long enough to
receive the DHCP offer (setting the timeout to 10 would keep the existing
behaviour). 2) I think it is unlikely that such a scenario exists at all. The
10-second timeout problem happens when there are problems with the interface
that prevent it from even sending out the DHCP request. I think it is very
unlikely (or even, impossible) that DHCP offers would be received on a dead
interface.
Based on the above points, I consider the regression potential to be
very low for this change. I do not expect anyone who is currently
using ipconfig successfully to notice this change.
I believe the only difference introduced by this is the reduction of
delays caused by dead or problematic network interfaces. Those error
delays are
[Sts-sponsors] [Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
** Changed in: openssl (Ubuntu) Assignee: Nicolas Bock (nicolasbock) => (unassigned) ** Changed in: openssl (Ubuntu Bionic) Assignee: Nicolas Bock (nicolasbock) => Bruce Elrick (virtuous-sloth) ** Changed in: openssl (Ubuntu Bionic) Status: Fix Committed => In Progress ** Tags removed: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: In Progress Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
