motd [on at least some instances] does not auto-update daily
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
base-files (Ubuntu) |
Fix Released
|
High
|
Brian Murray | ||
Bionic |
Fix Released
|
High
|
Brian Murray | ||
Cosmic |
Fix Released
|
Undecided
|
Brian Murray | ||
Disco |
Fix Released
|
Undecided
|
Brian Murray | ||
Eoan |
Fix Released
|
High
|
Brian Murray |
Bug Description
[Impact]
motd-news timer is not properly configured and may not run regularly so long running systems will not get an updated motd
[Test Case]
The motd-news.timer is known to be incorrectly configured because motd-news.services is a one shot service which will not become active. Subsequently, have a timer with OnUnitActiveSec is wrong and the timer will not work reliably. However, because it can work some of the time it is difficult to find a case where the timer always fails so test case will involve only confirming that the new timer is correct.
1) On a system with curl installed, install the new version of base-files
2) Run 'systemctl list-timers motd* --all
3) Confirm that "LEFT" is less than 12 hours (Its less than 24 hours because we don't want people to miss important messages)
4) Wait until "NEXT" is reached
5) Confirm that there is another "NEXT" and that the time stamp of /var/cache/
[Regression Potential]
I can't think of any on the client side as the job wasn't working as it was intended but it may cause extra load on the motd server.
Original Description
-------
I have a VM running on AWS. It was launched on May 9th:
$ uptime
05:26:21 up 12 days, 6:34, 1 user, load average: 0.00, 0.00, 0.00
$ date
Wed May 22 05:26:24 UTC 2019
I touched none of the system defaults, and yet the motd has not updated automatically.
$ ls -l /var/cache/
-rw-r--r-- 1 root root 0 May 9 22:53 /var/cache/
The systemd timer unit looks like this:
$ systemctl status motd-news.timer
● motd-news.timer - Message of the Day
Loaded: loaded (/lib/systemd/
Active: active (elapsed) since Thu 2019-05-09 22:51:58 UTC; 1 weeks 5 days ago
Trigger: n/a
May 09 22:51:58 ip-172-31-23-224 systemd[1]: Started Message of the Day.
If I run /etc/update-
Changed in base-files (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in base-files (Ubuntu Bionic): | |
importance: | Undecided → High |
status: | New → Triaged |
tags: | added: id-5ce840b53fe9fc1ccbddc1fa |
Changed in base-files (Ubuntu Eoan): | |
assignee: | nobody → Brian Murray (brian-murray) |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
Changed in base-files (Ubuntu Disco): | |
status: | New → In Progress |
assignee: | nobody → Brian Murray (brian-murray) |
Changed in base-files (Ubuntu Cosmic): | |
status: | New → In Progress |
assignee: | nobody → Brian Murray (brian-murray) |
Changed in base-files (Ubuntu Bionic): | |
status: | Triaged → In Progress |
assignee: | nobody → Brian Murray (brian-murray) |
I think this is related to https:/ /github. com/systemd/ systemd/ issues/ 6680, specifically this comment:
"hmm, so OnUnitActiveSec= operates relative to a unit becoming active, but Type=oneshot service units actually never become active, unless you combine them with RemainAfterExit=, hence the confusion...
Type=oneshot units after all do stuff during their start-up and when that's complete they go down again, they never stay up continiously... Hence, combining Type=oneshot with OnUnitActiveSec= can't really work... This is a big underdocumented though"
Which seems relevant, since:
$ cat /lib/systemd/ system/ motd-news. service Message of the Day network- online. target =man:update- motd(8)
[Unit]
Description=
After=
Documentation
[Service] /etc/update- motd.d/ 50-motd- news --force
Type=oneshot
ExecStart=