← Back to team overview

touch-packages team mailing list archive

[Bug 1426023] [NEW] apt-check should not be run from update-motd

 

Public bug reported:

If i launch a new cloud instance, and then ssh to it, my ssh login
blocks, stopping me from doing useful work while '/usr/lib/update-
notifier/apt-check' runs.

By far, the biggest offender of this slow login is /usr/lib/update-notifier/apt-check.
To demonstrate, a fresh cloud instance on azure.

## ssh to the instance and run a non-interactive command:
$ time ssh $cloudhost /bin/true
real	0m5.066s
user	0m0.045s
sys	0m0.004s

## ssh in and disable updates-available so it wont run at all
$ ssh $cloudhost sudo chmod -x /etc/update-motd.d/90-updates-available
$ time ssh $cloudhost /bin/true
real	0m2.459s
user	0m0.026s
sys	0m0.015s

## so disabling that bought us 2.5 seconds back.

## How about entirely disabling update-motd
$ ssh $cloudhost "sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.dist"
$ ssh $cloudhost "sudo sed -i '/^[^#].*pam_motd/s/^/#/' /etc/pam.d/sshd"
$ time ssh $cloudhost /bin/true
real  0m0.650s
user  0m0.041s
sys   0m0.004s

Note, that these things happen even for non-interactive logins, where
the message of the day is completely swallowed.  Automation tools suffer
this ever time they ssh to a ubuntu system.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: update-notifier-common 3.157
ProcVersionSignature: User Name 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
Date: Thu Feb 26 16:27:02 2015
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: update-notifier
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: pam (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: update-notifier (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug uec-images utopic

** Also affects: pam (Ubuntu)
   Importance: Undecided
       Status: New

** Description changed:

  If i launch a new cloud instance, and then ssh to it, my ssh login
  blocks, stopping me from doing useful work while '/usr/lib/update-
  notifier/apt-check' runs.
  
  By far, the biggest offender of this slow login is /usr/lib/update-notifier/apt-check.
  To demonstrate, a fresh cloud instance on azure.
  
  ## ssh to the instance and run a non-interactive command:
  $ time ssh $cloudhost /bin/true
  real	0m5.066s
  user	0m0.045s
  sys	0m0.004s
  
  ## ssh in and disable updates-available so it wont run at all
  $ ssh $cloudhost sudo chmod -x /etc/update-motd.d/90-updates-available
  $ time ssh $cloudhost /bin/true
  real	0m2.459s
  user	0m0.026s
  sys	0m0.015s
  
  ## so disabling that bought us 2.5 seconds back.
  
  ## How about entirely disabling update-motd
- $ ssh $cloudhost cp /etc/pam.d/sshd /etc/pam.d/sshd.dist
+ $ ssh $cloudhost "sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.dist"
  $ ssh $cloudhost "sudo sed -i '/^[^#].*pam_motd/s/^/#/' /etc/pam.d/sshd
  $ time ssh $cloudhost /bin/true
  real  0m0.650s
  user  0m0.041s
  sys   0m0.004s
  
- 
- Note, that these things happen even for non-interactive logins, where the message of the day is completely swallowed.  Automation tools suffer this ever time they ssh to a ubuntu system.
+ Note, that these things happen even for non-interactive logins, where
+ the message of the day is completely swallowed.  Automation tools suffer
+ this ever time they ssh to a ubuntu system.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: update-notifier-common 3.157
  ProcVersionSignature: User Name 3.16.0-30.40-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  ApportVersion: 2.14.7-0ubuntu8.2
  Architecture: amd64
  Date: Thu Feb 26 16:27:02 2015
  PackageArchitecture: all
  ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=<set>
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=<set>
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: update-notifier
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  If i launch a new cloud instance, and then ssh to it, my ssh login
  blocks, stopping me from doing useful work while '/usr/lib/update-
  notifier/apt-check' runs.
  
  By far, the biggest offender of this slow login is /usr/lib/update-notifier/apt-check.
  To demonstrate, a fresh cloud instance on azure.
  
  ## ssh to the instance and run a non-interactive command:
  $ time ssh $cloudhost /bin/true
  real	0m5.066s
  user	0m0.045s
  sys	0m0.004s
  
  ## ssh in and disable updates-available so it wont run at all
  $ ssh $cloudhost sudo chmod -x /etc/update-motd.d/90-updates-available
  $ time ssh $cloudhost /bin/true
  real	0m2.459s
  user	0m0.026s
  sys	0m0.015s
  
  ## so disabling that bought us 2.5 seconds back.
  
  ## How about entirely disabling update-motd
  $ ssh $cloudhost "sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.dist"
- $ ssh $cloudhost "sudo sed -i '/^[^#].*pam_motd/s/^/#/' /etc/pam.d/sshd
+ $ ssh $cloudhost "sudo sed -i '/^[^#].*pam_motd/s/^/#/' /etc/pam.d/sshd"
  $ time ssh $cloudhost /bin/true
  real  0m0.650s
  user  0m0.041s
  sys   0m0.004s
  
  Note, that these things happen even for non-interactive logins, where
  the message of the day is completely swallowed.  Automation tools suffer
  this ever time they ssh to a ubuntu system.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: update-notifier-common 3.157
  ProcVersionSignature: User Name 3.16.0-30.40-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  ApportVersion: 2.14.7-0ubuntu8.2
  Architecture: amd64
  Date: Thu Feb 26 16:27:02 2015
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: update-notifier
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1426023

Title:
  apt-check should not be run from update-motd

Status in pam package in Ubuntu:
  New
Status in update-notifier package in Ubuntu:
  New

Bug description:
  If i launch a new cloud instance, and then ssh to it, my ssh login
  blocks, stopping me from doing useful work while '/usr/lib/update-
  notifier/apt-check' runs.

  By far, the biggest offender of this slow login is /usr/lib/update-notifier/apt-check.
  To demonstrate, a fresh cloud instance on azure.

  ## ssh to the instance and run a non-interactive command:
  $ time ssh $cloudhost /bin/true
  real	0m5.066s
  user	0m0.045s
  sys	0m0.004s

  ## ssh in and disable updates-available so it wont run at all
  $ ssh $cloudhost sudo chmod -x /etc/update-motd.d/90-updates-available
  $ time ssh $cloudhost /bin/true
  real	0m2.459s
  user	0m0.026s
  sys	0m0.015s

  ## so disabling that bought us 2.5 seconds back.

  ## How about entirely disabling update-motd
  $ ssh $cloudhost "sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.dist"
  $ ssh $cloudhost "sudo sed -i '/^[^#].*pam_motd/s/^/#/' /etc/pam.d/sshd"
  $ time ssh $cloudhost /bin/true
  real  0m0.650s
  user  0m0.041s
  sys   0m0.004s

  Note, that these things happen even for non-interactive logins, where
  the message of the day is completely swallowed.  Automation tools
  suffer this ever time they ssh to a ubuntu system.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: update-notifier-common 3.157
  ProcVersionSignature: User Name 3.16.0-30.40-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  ApportVersion: 2.14.7-0ubuntu8.2
  Architecture: amd64
  Date: Thu Feb 26 16:27:02 2015
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: update-notifier
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1426023/+subscriptions


Follow ups

References