[Bug 684244] Re: Multiple issues with pam_motd update-motd code

[Steve Langasek]

Hi Steve,

If anything, using cron for this would be worse, not better.  The
information from some of the data sources used here is dynamic enough
that, when this was being done with cron previously, the job was set to
a five minute interval - and since cron itself opens a PAM session for
each job, that meant hammering the disk once every five minutes to write
out security logs.

On a default system, only ssh and login will call pam_motd; and
typically both of these are rather infrequent events.  Of all the
possible implementations (and we did try them all; see bug #399071),
doing the update inline in pam_motd was determined to be the least
wasteful despite the possible problem it introduces with login-time
interactivity.

Can you help pin down why it takes 5 seconds to generate this file?  The
individual component scripts under /etc/update-motd.d now each do their
own out-of-dateness checks in shell; there will still be some cost, but
I wouldn't expect it to add up to a whole 5 seconds on every login.  On
the first login after installation, yes, it will take some time to do
the initial generation; but afterwards all the information is cached in
/var/lib (which should be /var/cache, heh) and only the concatenation to
/var/run/motd is duplicated.

To answer your specific questions:

> 1. Why on earth is *every* login updating a global file (/etc/motd ->
/var/run/motd)?

To avoid unnecessarily updating it when people *aren't* logging into a
service that uses pam_motd.  On typical desktop systems, console logins
happen approximately never.  We could add a 5 minute cache timeout or so
to /var/run/motd itself.  I'm not sure how much that would help, really.

> a. Why spam every user?

It's... the motd.  That's what it's for.  Now, it's certainly designed
to be tunable *what* information gets included in the motd; perhaps
Linaro would prefer not to use any dynamic motd for instance.

> b. Why even write to the file every time? It's being generated on all
logins, so there doesn't seem to be any useful caching go on.

Well, it's cached in the sense that anything else which looks at the
motd without using pam_motd will be able to get the updated information.
But otherwise, yes, not being cached very effectively.

> 3. I don't see any locking around the updates of /var/run/motd.new, so
it seems that multiple parallel logins could easily case corruption

Confirmed, that appears to be a bug.  Patches welcome of course.  It's
not the highest priority for fixing, given that a corrupted motd isn't
particularly fatal.

>  4. No documentation of any of this in pam_motd(8)

There is a link to update-motd(5) which documents this, but you're right
that it should be called out more explicitly.

** Changed in: pam (Ubuntu)
   Importance: Undecided => Medium

** Changed in: pam (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/684244

Title:
  Multiple issues with pam_motd update-motd code

Status in “pam” package in Ubuntu:
  Triaged

Bug description:
  Package: libpam-modules
  Version: 1.1.1-2ubuntu5

  Running Lucid on a Beagleboard, wondering why logins take so long.
  Horrified to find that the problem is pam_motd... Several issues:

   1. Why on earth is *every* login updating a global file (/etc/motd -> /var/run/motd)?
      a. Why spam every user?
      b. Why even write to the file every time? It's being generated on all logins, so there doesn't seem to be any useful caching go on.
   2. This is adding ~5 seconds of startup lag to every login, which is annoying
   3. I don't see any locking around the updates of /var/run/motd.new, so it seems that multiple parallel logins could easily case corruption
   4. No documentation of any of this in pam_motd(8)

  If you must update motd automatically, then surely running something
  via cron would be better than this messy hack?