My client has 200+ devices automatically uploading information via sftp and scp to a server every few minutes. After a recent update, I noticed the load on their server spiking through the roof. Upon investigation, I discovered a horde of landscape-sysinfo and /usr/bin/lsb_release processes running that correlated with login session notifications in /etc/syslog and the load spikes.
It appears that even in non-interactive sessions where this information will never be seen, the configuration options below in /etc/pam.d/sshd cause these items to be launched (in fact, probably everything in /etc/update-motd.d). This only started on the system in question after a recent set of system updates were in stalled.
The content of /etc/update-motd.d/* really, really, really shouldn't be executed if the session in question is not interactive, as it provides no value at all. Unfortunately, to disable it for these non-interactive sessions, we also have to disable it for the interactive ones as well where it has some value (though not enough to make spiking the load on this server through the roof an acceptable tradeoff).
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
#session optional pam_motd.so motd=/run/motd.dynamic
#session optional pam_motd.so noupdate
Also, looking at the script 00-header in /etc/update-motd.d/, /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release does include the necessary information:
[ -r /etc/lsb-release ] && . /etc/lsb-release
if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
# Fall back to using the very slow lsb_release utility DISTRIB_DESCRIPTION=$(lsb_release -s -d)
fi
My client has 200+ devices automatically uploading information via sftp and scp to a server every few minutes. After a recent update, I noticed the load on their server spiking through the roof. Upon investigation, I discovered a horde of landscape-sysinfo and /usr/bin/ lsb_release processes running that correlated with login session notifications in /etc/syslog and the load spikes.
It appears that even in non-interactive sessions where this information will never be seen, the configuration options below in /etc/pam.d/sshd cause these items to be launched (in fact, probably everything in /etc/update- motd.d) . This only started on the system in question after a recent set of system updates were in stalled.
The content of /etc/update- motd.d/ * really, really, really shouldn't be executed if the session in question is not interactive, as it provides no value at all. Unfortunately, to disable it for these non-interactive sessions, we also have to disable it for the interactive ones as well where it has some value (though not enough to make spiking the load on this server through the roof an acceptable tradeoff).
# Print the message of the day upon successful login. motd.dynamic
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
#session optional pam_motd.so motd=/run/
#session optional pam_motd.so noupdate
Also, looking at the script 00-header in /etc/update- motd.d/ , /usr/bin/ lsb_release is being improperly launched, as /etc/lsb_release does include the necessary information:
[ -r /etc/lsb-release ] && . /etc/lsb-release
if [ -z "$DISTRIB_ DESCRIPTION" ] && [ -x /usr/bin/ lsb_release ]; then
DISTRIB_ DESCRIPTION= $(lsb_release -s -d)
# Fall back to using the very slow lsb_release utility
fi
# cat /etc/lsb-release RELEASE= 16.04 CODENAME= xenial DESCRIPTION= "Ubuntu 16.04.7 LTS"
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_