motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable

A possible fix would be to make the unit execution conditional to the update-motd fragment being executable:

  [Unit]
  ConditionFileIsExecutable=/etc/update-motd.d/50-motd-news

I'm not sure if this should be added to motd-news.service, motd-news.timer or both.

I have the same problem and it looks like this issue brings my server in real trouble. I deactivated this services completly now and hope it helps.

There are many alternatives here. What you describe is one, and you could then also add a systemd override with that exec check. A bit cumbersome, though.

Another one is specific to this service, and that is to set ENABLED=0 in /etc/default/motd-news.

I think fixing this doesn't warrant an SRU, but should be considered for the devel release of ubuntu (groovy at the moment).

On 2020-05-06 2:49 p.m., Andreas Hasenack wrote:
> There are many alternatives here.

IIRC, `chmod -x` snippets from /etc/update-motd.d/ was the way to go a
few releases ago when it was consumed by run-parts.

> I think fixing this doesn't warrant an SRU, but should be considered for
> the devel release of ubuntu (groovy at the moment).

It's merely to avoid harmless surprise and keep the old sysadmins happy,
certainly not worth a SRU.

Thanks,
Simon

"Another one is specific to this service, and that is to set ENABLED=0 in /etc/default/motd-news."

This file no longer exists by default in Ubuntu 22.04 Jammy. The language in the fix in many places including https://ubuntu.com/legal/motd is to change a number in a file that isn't there.

As you know, systemd services that are disabled can still be enabled.

Simon Déziel (sdeziel) wrote:
> IIRC, `chmod -x` snippets from /etc/update-motd.d/ was the way to go a
> few releases ago when it was consumed by run-parts.

In 22.04 it's still handled by run-parts, and the man page documents it as such. Specifically by

$ strings /lib/x86_64-linux-gnu/security/pam_motd.so | grep run-parts
/usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new

in its primary use case. The "fetch new ads on boot" motd-news.service for this bug report runs one of the scripts directly, but the directory is still a run-parts input.

We could disable scripts by renaming them to something that won't be found by the '--lsbsysinit' file patterns, but that would only solve the problem for "at login" updates, not the "at boot" updates through systemd.

> It's merely to avoid harmless surprise and keep the old sysadmins happy,

Service errors is hardly a "surprise", and you don't need to be condescending about it.

wontfix (wontfix) wrote:
> and that is to set ENABLED=0 in /etc/default/motd-news."
>
> This file no longer exists by default in Ubuntu 22.04 Jammy.

$ grep VERSION /etc/os-release
VERSION_ID="22.04"
VERSION="22.04 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
$ dpkg -S /etc/default/motd-news
motd-news-config: /etc/default/motd-news
$ apt show motd-news-config
Package: motd-news-config
Priority: optional
Source: base-files
Task: cloud-image, ubuntu-wsl, server, ubuntu-server-raspi
APT-Manual-Installed: no
[several header elided]

It certainly existed by default from the beginning of the server installation I'm working with. However, it's "priority: optional" so perhaps that's what you mean by "not default"; it likely wouldn't be there for a standard desktop installation.

I should also have mentioned that 'ubuntu-server' has a hard dependency on 'motd-news-config', so anybody wanting a standard server-type installation will automatically get the advert updater and /etc/default/motd-news.