pam_motd needs a module option to disable in-line dynamic updates
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Landscape Client |
Invalid
|
Undecided
|
Unassigned | ||
pam (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
1) lsb_release -rd
Description: Ubuntu 10.04.2 LTS
Release: 10.04
2) Installiert: 1.1.1-2ubuntu5.3
Kandidat: 1.1.1-2ubuntu5.3
Versions-Tabelle:
*** 1.1.1-2ubuntu5.3 0
500 http://
500 http://
100 /var/lib/
1.1.1-2ubuntu2 0
500 http://
3) Login on systems with high load/a lot of io wait via ssh should still be possible.
4) On servers with high load or a lot of io wait login times out, because pam_motd does io intensive calculations. This hurts even more when using nagios check_by_ssh. There should be a way to use a cron job again (like update-motd did). Logging into a system is more important than motd.
Changed in pam (Ubuntu): | |
status: | Won't Fix → Triaged |
summary: |
- pam_motd performance problems + pam_motd needs a module option to disable in-line dynamic updates |
Changed in pam (Ubuntu): | |
importance: | Undecided → Medium |
tags: | added: bitesize |
Thank you for reporting this issue and helping to improve Ubuntu.
I understand your concern about the performance impact; however, we are not going to change the default behavior of pam_motd in Ubuntu. There is consensus that the dynamic motd should be enabled by default, and the current behavior is the best way to implement this: the cronjob you refer to was abandoned because it was very wasteful in the common case.
You are right that the ability to log in is more important than presenting a motd. If this behavior is a problem for you, there are several ways that you can disable it:
- comment out the 'pam_motd' line in /etc/pam.d/sshd if you don't want to display a motd.
- delete the contents of the /etc/update-motd.d directory.
- chmod -x the scripts in /etc/update-motd.d that you don't want to run.
Given this existing array of options, I don't think there's anything further that we can do here short of changing the default behavior, which we won't do; so marking this bug "wontfix".