The timer is still incorrect as we can see here:

 $ systemctl list-timers --all 
NEXT                         LEFT          LAST                         PASSED  
           UNIT                         ACTIVATES
Wed 2019-07-03 10:31:55 PDT  36min left    Wed 2019-07-03 09:31:58 PDT  23min 
ago          anacron.timer                anacron.service
Wed 2019-07-03 11:53:16 PDT  1h 57min left Tue 2019-07-02 22:48:05 PDT  11h ago 
           apt-daily.timer              apt-daily.service
Wed 2019-07-03 15:28:41 PDT  5h 33min left Tue 2019-07-02 15:28:41 PDT  18h ago 
           systemd-tmpfiles-clean.timer systemd-tmpfiles-clea
Wed 2019-07-03 22:07:28 PDT  12h left      Tue 2019-07-02 01:10:22 PDT  1 day 
8h ago       mdmonitor-oneshot.timer      mdmonitor-oneshot.ser
Thu 2019-07-04 00:00:00 PDT  14h left      Wed 2019-07-03 00:00:01 PDT  9h ago  
           logrotate.timer              logrotate.service
Thu 2019-07-04 00:00:00 PDT  14h left      Wed 2019-07-03 00:00:01 PDT  9h ago  
           man-db.timer                 man-db.service
Thu 2019-07-04 06:45:10 PDT  20h left      Wed 2019-07-03 06:18:41 PDT  3h 
36min ago       apt-daily-upgrade.timer      apt-daily-upgrade.ser
Sun 2019-07-07 03:10:43 PDT  3 days left   Sun 2019-06-30 03:11:23 PDT  3 days 
ago         e2scrub_all.timer            e2scrub_all.service
Sun 2019-07-07 23:51:21 PDT  4 days left   Mon 2019-06-24 15:03:57 PDT  1 weeks 
1 days ago mdcheck_start.timer          mdcheck_start.service
Mon 2019-07-08 00:00:00 PDT  4 days left   Mon 2019-07-01 00:00:01 PDT  2 days 
ago         fstrim.timer                 fstrim.service
n/a                          n/a           n/a                          n/a     
           mdcheck_continue.timer       mdcheck_continue.serv
n/a                          n/a           Tue 2019-06-25 04:05:23 PDT  1 weeks 
1 days ago motd-news.timer              motd-news.service
n/a                          n/a           n/a                          n/a     
           snapd.snap-repair.timer      snapd.snap-repair.ser
n/a                          n/a           Mon 2019-06-24 15:13:25 PDT  1 weeks 
1 days ago ureadahead-stop.timer        ureadahead-stop.servi

14 timers listed.
[  9:55AM 11039 ]  [ bdmurray@impulse:~/source-trees/daisy/trunk ]
 $ systemctl status motd-news.timer
● motd-news.timer - Message of the Day
   Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled; vendor preset: 
enabled)
   Active: active (elapsed) since Mon 2019-06-24 15:12:33 PDT; 1 weeks 1 days 
ago
  Trigger: n/a

Jun 24 15:12:33 impulse systemd[1]: Started Message of the Day.
[  9:56AM 11041 ]  [ bdmurray@impulse:~/source-trees/daisy/trunk ]
 $ apt-cache policy base-files
base-files:
  Installed: 10.2ubuntu3
  Candidate: 10.2ubuntu3
  Version table:
 *** 10.2ubuntu3 500
        500 http://192.168.10.7/ubuntu eoan/main amd64 Packages
        100 /var/lib/dpkg/status


** Changed in: base-files (Ubuntu Eoan)
       Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1829968

Title:
  motd [on at least some instances] does not auto-update daily

Status in base-files package in Ubuntu:
  In Progress
Status in base-files source package in Bionic:
  Triaged
Status in base-files source package in Cosmic:
  New
Status in base-files source package in Disco:
  New
Status in base-files source package in Eoan:
  In Progress

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 system being tested must have curl installed - base-files does not depend 
on it because reasons.
  1) Run 'systemctl status mot-news.timer'
  2) Observe that the Trigger section is n/a

  With the version of the package from -proposed the Trigger section
  should instead contain something like the following:

  Trigger: Mon 2019-06-17 11:42:25 PDT; 20min left

  One should also wait to ensure that the trigger actually ran and that
  /var/cache/motd-news has been updated.

  [Regression Potential]
  I can't think of any on the client side as the job wasn't working at all 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/motd-news
    -rw-r--r-- 1 root root 0 May  9 22:53 /var/cache/motd-news

  The systemd timer unit looks like this:

    $ systemctl status motd-news.timer
    ● motd-news.timer - Message of the Day
       Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled; vendor 
preset: enabled)
       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-motd.d/50-motd-news --force manually, the file
  does update correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1829968/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to