[SRU] 50-motd-news costs 5 seconds every login on firewalled systems
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
base-files (Ubuntu) |
Fix Released
|
High
|
Dustin Kirkland | ||
Zesty |
Fix Released
|
High
|
Dustin Kirkland | ||
Artful |
Fix Released
|
High
|
Dustin Kirkland |
Bug Description
I noticed quite a long time to login to some of my systems via ssh (or scp).
Investigating lead me to find out that the '50-motd-news' file
(/etc/update-
In line 108 [1] it does something like:
curl --connect-timeout "5" --max-time "5" -A "..." -o - https:/
The systems I'm seeing this on are in a lab and do not have access to https:/
The way the lab is configured, they just end up timing out. So every scp or ssh connection
or other path to trigger update-motd will cost 5 seconds.
======= SRU =======
[ IMPACT ]
This bug affects Ubuntu 17.04 systems which cannot reach the internet (more specifically, https:/
[ TEST CASE ]
You can either test this on a firewalled system. Or, if you can hack an entry in your local /etc/hosts for motd.ubuntu.com for an invalid IP address. Without the fix, you'll experience a 5 second delay on login. With the fix, you'll login immediately.
Failure case:
$ lxc launch ubuntu:17.04 LP1691901
$ lxc exec LP1691901 bash
# ssh-import-id kirkland
# echo 192.168.0.0 motd.ubuntu.com >> /etc/hosts
# rm -f /var/cache/
# exit
$ time ssh root@$(lxc list | grep LP1691901 | awk '{print $6}') true
real 0m5.333s
user 0m0.016s
sys 0m0.000s
Apply the fix.
$ time ssh root@$(lxc list | grep LP1691901 | awk '{print $6}') true
real 0m0.316s
user 0m0.008s
sys 0m0.008s
[ REGRESSION ]
This is a simple, safe fix with minimal regression potential:
diff -Nru base-files-
--- base-files-
+++ base-files-
@@ -51,9 +51,13 @@
# If we're not forcing an update, and we have a cached motd-news file,
# then just print it and exit as quickly as possible, for login performance.
# Note that systemd should keep this cache file up to date, asynchronously
-if [ "$FORCED" != "1" ] && [ -r $CACHE ]; then
- echo
- safe_print $CACHE
+if [ "$FORCED" != "1" ]; then
+ if [ -r $CACHE ]; then
+ echo
+ safe_print $CACHE
+ else
+ : > $CACHE
+ fi
exit 0
fi
@@ -111,7 +115,9 @@
# Try to update the cache
- fi
+ else
+ : > "$CACHE"
+ fi
done
rm -f "$NEWS" "$NEWS.err"
exit 0
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: base-files 9.6ubuntu13
ProcVersionSign
Uname: Linux 4.10.0-21-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
Date: Fri May 19 01:11:30 2017
Ec2AMI: ami-0000004f
Ec2AMIManifest: FIXME
Ec2Availability
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: base-files
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile.
summary: |
- 50-motd-news costs 5 seconds every login on disconnected systems + 50-motd-news costs 5 seconds every login on firewalled systems |
Changed in base-files (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in base-files (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in base-files (Ubuntu): | |
assignee: | nobody → Dustin Kirkland (kirkland) |
status: | Triaged → In Progress |
Changed in base-files (Ubuntu Zesty): | |
assignee: | nobody → Dustin Kirkland (kirkland) |
status: | New → In Progress |
importance: | Undecided → High |
Changed in base-files (Ubuntu Zesty): | |
status: | In Progress → Fix Committed |
Changed in base-files (Ubuntu Artful): | |
status: | In Progress → Fix Committed |
summary: |
- 50-motd-news costs 5 seconds every login on firewalled systems + [SRU] 50-motd-news costs 5 seconds every login on firewalled systems |
description: | updated |
description: | updated |
Changed in base-files (Ubuntu Zesty): | |
status: | Fix Committed → In Progress |
I've adjusted the bug description to match my understanding of the actual problem.
AIUI this does not happen on a disconnected system; if motd.ubuntu.com cannot resolve or returns ECONNREFUSED or EHOSTUNREACH, there should be no 5-second delay. The error only happens on a system which has routes, but has a firewall that drops packets instead of responding to the request. (Or when motd.u.c is actually down.)
So, what you appear to be describing here is a deliberate design tradeoff. Unless you are recommending a different timeout (if so, what value?) or asking for this to be disabled altogether (in which case I will refer you to Dustin), I think the only solution here is for your lab to have suitable firewall+proxy settings.