Double motd when ssh'ing into 10.04.2

[Barry Warsaw]

When I ssh into my 10.04.2 servers I get two motd print outs. The first one appears to be current-ish, but the second one is way out of date. The first motd contains this:

  System information as of Fri May 20 01:36:13 EDT 2011

while the one just following says this:

  System information as of Mon Apr 18 17:31:22 EDT 2011

(Note though that the time stamp lies. Current time is 17:40 EDT on May 19, and the first time stamp doesn't correspond to UTC, so I don't really know what time it thinks it is. Ah, ntp must not be running as the time stamp corresponds to what `date` tells me.)

I don't remember when the double motds started showing up. This does occur on both 10.04.2 servers I have, and I have confirmation through the DC LoCo that others are seeing this as well.

Note that you can log onto the console without ssh and see the same double motd.

[nutznboltz (nutznboltz-deactivatedaccount)]

as a work-around:

sudo rm /etc/motd.tail

then log out and back in again.

[nutznboltz (nutznboltz-deactivatedaccount)]

@Joshua Lückers openssh does not configure MOTD.

$ dpkg -S /etc/update-motd.d
base-files, update-notifier-common, update-manager-core: /etc/update-motd.d

[nutznboltz (nutznboltz-deactivatedaccount)]

$ grep motd.tail /etc/update-motd.d/99-footer
# motd.tail is reserved for the admin to append static
[ -f /etc/motd.tail ] && cat /etc/motd.tail || true

$ dpkg -S /etc/update-motd.d/99-footer
base-files: /etc/update-motd.d/99-footer

[nutznboltz (nutznboltz-deactivatedaccount)]

 Manual page update-motd(5)

      Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8)
       as the root user at each login, and this information is concatenated in
       /var/run/motd. The order of script execution is determined by the run-
       parts(8) --lsbsysinit option (basically alphabetical order, with a few
       caveats).

pam-1.1.1/debian/patches-applied/update-motd (fragment)

+ /* Run the update-motd dynamic motd scripts, outputting to /var/run/motd.
+ If /etc/motd -> /var/run/motd, the displayed MOTD will be dynamic.
+ Otherwise, the admin can force a static MOTD by breaking that symlink
+ and publishing into an /etc/motd text file. */
+ if ((stat("/etc/update-motd.d", &st) == 0) && S_ISDIR(st.st_mode)) {
+ if (!system("run-parts --lsbsysinit /etc/update-motd.d > /var/run/motd.new"))
+ rename("/var/run/motd.new", "/var/run/motd");
     }

[nutznboltz (nutznboltz-deactivatedaccount)]

After building a new VM from ubuntu-10.04.2-server-amd64.iso it looks like the issue is in one of these:

landscape-client (1.5.0.1-0ubuntu0.10.04.0) lucid; urgency=low

  * New upstream version
    - Fix smart-update failing its very first run (LP: #562496)
    - Depend on pythonX.Y-dbus and pythonX.Y-pycurl (LP: #563063)
    - Make only one request at a time to retrieve EC2 instances (LP: #567515)

 -- Free Ekanayaka <email address hidden> Wed, 21 Apr 2010 12:31:28 +0200

landscape-client (1.5.0-0ubuntu0.10.04.0) lucid; urgency=low

  * New upstream version (LP: #557244)
    - Fix package-changer running before smart-update has completed (LP: #542215)
    - Report the version of Eucalyptus used to generate topology data (LP: #554007)
    - Enable the Eucalyptus plugin by default, if supported (LP: #546531)
    - Use a whitelist of allowed filesystem types to instead of a blacklist (LP: #351927)
    - Report the update-manager logs to the server (LP: #503384)
    - Turn off Curl's DNS caching for requests. (LP: #522688)

 -- Free Ekanayaka <email address hidden> Wed, 07 Apr 2010 16:27:45 +0200

[nutznboltz (nutznboltz-deactivatedaccount)]

1. Create new VM from ubuntu-10.04.2-server-amd64.iso

2. log in. Notice motd is displayed twice

3. log out and back in again. Notice motd is displayed only once

4. apply updates. Log out and back in again. Notice motd is displayed twice.

5. remove /etc/motd.tail and log out and back in again. Notice motd is displayed only once.

[nutznboltz (nutznboltz-deactivatedaccount)]

2. log in. Notice motd is displayed twice

This isn't true, there's some other one-time message displayed.

Running

sudo strace -o apt.str -s 4096 -f aptitude dist-upgrade

on a fresh VM shows that the issue is in the postinstall script of the initscripts package.

sysvinit-2.87dsf/debian/initscripts.postinst fragment:

#
# Set up motd stuff, putting variable file in /var/run/
#
if [ ! -f /etc/motd.tail ]
then
        if [ -f /etc/motd ]
        then
                sed 1d /etc/motd > /etc/motd.tail
                [ -s /etc/motd.tail ] || rm -f /etc/motd.tail
        fi
fi

[nutznboltz (nutznboltz-deactivatedaccount)]

sysvinit (2.87dsf-4ubuntu17) lucid; urgency=low

  * debian/initscripts/etc/init.d/sendsigs: additional upstart jobs may be
    /started/ on shutdown after this script has first been invoked; so don't
    assume the list of known jobs is constant, instead requery initctl before
    each killall5 -CONT to properly exclude any new jobs upstart knows about
    so that we aren't waiting an extra 10 seconds for no reason.
    LP: #537262.

 -- Steve Langasek <email address hidden> Tue, 30 Mar 2010 00:08:33 -0700

[nutznboltz (nutznboltz-deactivatedaccount)]

Looks like the code in sysvinit-2.87dsf/debian/initscripts.postinst that tries to preserve an existing motd by turning it into a motd.tail only makes sense if /etc/motd isn't already symlink to a generated file.

#
# Set up motd stuff, putting variable file in /var/run/
#
if [ ! -f /etc/motd.tail ]
then
        if [ -f /etc/motd ]
        then
                sed 1d /etc/motd > /etc/motd.tail
                [ -s /etc/motd.tail ] || rm -f /etc/motd.tail
        fi
fi

should be

#
# Set up motd stuff, putting variable file in /var/run/
#
if [ ! -f /etc/motd.tail ]
then
        if [ -f /etc/motd -a ! -L /etc/motd ]
        then
                sed 1d /etc/motd > /etc/motd.tail
                [ -s /etc/motd.tail ] || rm -f /etc/motd.tail
        fi
fi

The additional "-a ! -L /etc/motd" part would make the /etc/motd to /etc/motd.tail only happen if /etc/motd was not a symlink.

[wangweilin (accounts-computational-chemistry)]

My case was a little different but I think is part of this problem.

I acctually had 4 motd when logging in with ssh.

motd #1
motd #2
motd #1
motd #2

which lead me to the conclusion that there must be 2 problems.

The First problem was the motd.tail which posted the first message (motd #1) ... the last login message

The second part of the Problem was the double posting of motd #2 which did not occur with the standard login.
So I checked the /etc/ssh/sshd_config and set the "PrintMotd" to "no" which resulted in the correct display.

Basicly there are 2 "bugs" resulting in simular problems.

Regards