Comment 2 for bug 684244

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.