50-motd-news costs 5 seconds every login on firewalled systems

Bug #1691901 reported by Scott Moser on 2017-05-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
base-files (Ubuntu)

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-motd.d/50-motd-news) was the primary cost.

In line 108 [1] it does something like:
 curl --connect-timeout "5" --max-time "5" -A "..." -o - https://motd.ubuntu.com

The systems I'm seeing this on are in a lab and do not have access to https://motd.ubuntu.com.
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.

[1] https://git.launchpad.net/~usd-import-team/ubuntu/+source/base-files/tree/update-motd.d/50-motd-news?h=applied/ubuntu/zesty#n108

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: base-files 9.6ubuntu13
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
Architecture: amd64
Date: Fri May 19 01:11:30 2017
Ec2AMI: ami-0000004f
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
 PATH=(custom, no user)
SourcePackage: base-files
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.update-motd.d.50-motd-news: 2017-05-19T01:10:25.572110

Scott Moser (smoser) wrote :
Steve Langasek (vorlon) on 2017-05-23
summary: - 50-motd-news costs 5 seconds every login on disconnected systems
+ 50-motd-news costs 5 seconds every login on firewalled systems
Steve Langasek (vorlon) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers