[OH3] motd doesn't show correct update count

eikowagenknecht commented 3 years ago

Issue information:

My openHAB 3 instance has been running for 22 days straight now so I though I'd check for linux updates. But nothing shows up in motd:

But updates are available:

Also there seems to be some duplicate configuration of sources (openhab / openhab2).

I have not touched anything systemwise. This is a default out-of-the-box installation.

System information:

Pi4, installed with the 1.6.2 image.

cat /etc/os-release and uname -m:

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

armv7l

eikowagenknecht commented 3 years ago

For reference, this is what it looks like and should look like with an OH2 installation:

mstormi commented 3 years ago

Cannot reproduce on a fresh install. Run systemctl list-timers and show output. Eventually do systemctl reset-failed. Run systemctl start firemotd.service to regenerate motd and see after some minutes if that made a difference (login again).

eikowagenknecht commented 3 years ago

Thanks for trying to reproduce this.

openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT                         LEFT     LAST                         PASSED             UNIT                         ACTIVATES
Thu 2021-01-14 21:51:49 CET  10h left Wed 2021-01-13 21:51:49 CET  13h ago            systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-01-14 23:27:36 CET  12h left Thu 2021-01-14 07:35:19 CET  3h 40min ago       apt-daily.timer              apt-daily.service
Fri 2021-01-15 00:00:00 CET  12h left Thu 2021-01-14 00:00:22 CET  11h ago            logrotate.timer              logrotate.service
Fri 2021-01-15 00:00:00 CET  12h left Thu 2021-01-14 00:00:22 CET  11h ago            man-db.timer                 man-db.service
Fri 2021-01-15 06:16:10 CET  19h left Thu 2021-01-14 06:39:19 CET  4h 36min ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
n/a                          n/a      Wed 2020-12-23 04:58:19 CET  3 weeks 1 days ago firemotd.timer               firemotd.service

openhabian@pi-openhab3:~ $ systemctl reset-failed
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or other units.
Authenticating as: ,,, (openhabian)
Password:
==== AUTHENTICATION COMPLETE ===
openhabian@pi-openhab3:~ $

openhabian@pi-openhab3:~ $ systemctl start firemotd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'firemotd.service'.
Authenticating as: ,,, (openhabian)
Password:
==== AUTHENTICATION COMPLETE ===
openhabian@pi-openhab3:~ $

Unfortunately I updated yesterday so currently "0" is the correct value:

openhabian@pi-openhab3:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Not sure it it's possible to downgrade some not-so-important package to test this.

eikowagenknecht commented 3 years ago

Is the duplicate configuration of sources on purpose? If not, should I open another Issue or do you think this is related?

W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB.UTF-8) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1
W: Target Translations (main/i18n/Translation-en_GB.UTF-8) is configured multiple times in /etc/apt/sources.list.d/openhab.list:1 and /etc/apt/sources.list.d/openhab2.list:1

mstormi commented 3 years ago

Is the duplicate configuration of sources on purpose? If not, should I open another Issue or do you think this is related?

Depends and no. Just delete either of those files depending on which OH version you want to keep running.

mstormi commented 3 years ago

openhabian@pi-openhab3:~ $ systemctl start firemotd.service
Not sure if it's possible to downgrade some not-so-important package to test this.

A firemotd run regenerates all of the banner so you can change anything that would affect this. Or just install some package with an explicit older version (apt-cache madison pkg .... apt install pkg=) Try list-timers again to check scheduled runs.

eikowagenknecht commented 3 years ago

Depends and no. Just delete either of those files depending on which OH version you want to keep running.

Ok, the current content is the same anyways:

openhabian@pi-openhab3:/etc/apt/sources.list.d $ cat openhab.list
deb https://dl.bintray.com/openhab/apt-repo2 stable main
openhabian@pi-openhab3:/etc/apt/sources.list.d $ cat openhab2.list
deb https://dl.bintray.com/openhab/apt-repo2 stable main

So I delete the openhab2.list (openhab 2 was never installed on this system, only openhab 3).

eikowagenknecht commented 3 years ago

list-timers after the commands above:

openhabian@pi-openhab3:/etc/apt/sources.list.d $ systemctl list-timers
NEXT                         LEFT     LAST                         PASSED             UNIT                         ACTIVATES
Thu 2021-01-14 21:51:49 CET  10h left Wed 2021-01-13 21:51:49 CET  13h ago            systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-01-14 23:27:36 CET  11h left Thu 2021-01-14 07:35:19 CET  4h 10min ago       apt-daily.timer              apt-daily.service
Fri 2021-01-15 00:00:00 CET  12h left Thu 2021-01-14 00:00:22 CET  11h ago            logrotate.timer              logrotate.service
Fri 2021-01-15 00:00:00 CET  12h left Thu 2021-01-14 00:00:22 CET  11h ago            man-db.timer                 man-db.service
Fri 2021-01-15 06:16:10 CET  18h left Thu 2021-01-14 06:39:19 CET  5h 6min ago        apt-daily-upgrade.timer      apt-daily-upgrade.service
n/a                          n/a      Wed 2020-12-23 04:58:19 CET  3 weeks 1 days ago firemotd.timer               firemotd.service

6 timers listed.
Pass --all to see loaded but inactive timers, too.

A firemotd run regenerates all of the banner so you can change anything that would affect this.

Uptime, load etc. is always updated correctly on every login. That was the case before as well, only apt updates were always 0.

Or just install some package with an explicit older version (apt-cache madison pkg .... apt install pkg=)

That doesn't seem to work because only the newest version is shown (example here is for tzdata, which I updated yesterday):

openhabian@pi-openhab3:/etc/apt/sources.list.d $ apt-cache madison tzdata
    tzdata | 2020e-0+deb10u1 | http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

After a system reboot list-timers output is:

openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT                         LEFT      LAST                         PASSED       UNIT                         ACTIVATES
Thu 2021-01-14 12:10:51 CET  6min left n/a                          n/a          systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2021-01-15 00:00:00 CET  11h left  Thu 2021-01-14 00:00:22 CET  12h ago      logrotate.timer              logrotate.service
Fri 2021-01-15 00:00:00 CET  11h left  Thu 2021-01-14 00:00:22 CET  12h ago      man-db.timer                 man-db.service
Fri 2021-01-15 01:21:48 CET  13h left  Thu 2021-01-14 07:35:19 CET  4h 29min ago apt-daily.timer              apt-daily.service
Fri 2021-01-15 06:56:51 CET  18h left  Thu 2021-01-14 06:39:19 CET  5h 25min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
n/a                          n/a       Thu 2021-01-14 11:55:43 CET  9min ago     firemotd.timer               firemotd.service

So it looks like the firemotd.timer was not working until I rebooted the system?

.timer file shows:

openhabian@pi-openhab3:~ $ cat /etc/systemd/system/firemotd.timer
[Unit]
Description=Daily generation of FireMotD stats

[Timer]
OnCalendar=*-*-* 00:00
RandomizedDelaySec=6h
Persistent=true

[Install]
WantedBy=timers.target

I'll keep an eye on this when the next apt updates are available.

eikowagenknecht commented 3 years ago

According to https://www.freedesktop.org/software/systemd/man/systemd.time.html the usual syntax would be OnCalendar=*-*-* 00:00:00 or OnCalendar=daily. Maybe this has to do something with the missing ":00" in the .timer file? (Just a guess!)

mstormi commented 3 years ago

missing ":00" in the .timer file?

try for yourself but the link you quote also says my syntax is valid too

eikowagenknecht commented 3 years ago

You're right, I missed that sentence. I tried

Change the syntax to "daily"
sudo systemctl reenable --now firemotd.timer -> No change (still "n/a" as NEXT which I think is a bad thing and shows the timer's not working)

Then I tried:

sudo systemctl stop firemotd.timer

sudo systemctl start firemotd.timer -> Now finally it appears in the list with a next date:

openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT                         LEFT     LAST                         PASSED       UNIT                         ACTIVATES
Thu 2021-01-14 20:43:37 CET  7h left  Thu 2021-01-14 07:35:19 CET  5h 52min ago apt-daily.timer              apt-daily.service
Fri 2021-01-15 00:00:00 CET  10h left Thu 2021-01-14 00:00:22 CET  13h ago      logrotate.timer              logrotate.service
Fri 2021-01-15 00:00:00 CET  10h left Thu 2021-01-14 00:00:22 CET  13h ago      man-db.timer                 man-db.service
Fri 2021-01-15 02:30:02 CET  13h left Thu 2021-01-14 11:55:43 CET  1h 32min ago firemotd.timer               firemotd.service
Fri 2021-01-15 06:24:21 CET  16h left Thu 2021-01-14 06:39:19 CET  6h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Fri 2021-01-15 12:11:02 CET  22h left Thu 2021-01-14 12:11:02 CET  1h 17min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

No idea why that helped, though.

I can do all the enabling, diasabling and reenabling I like after that, it still shows up in NEXT (only when it's not currently disabled of course).

As said before, I did not tamper with the system at all (yet) because it's only an openHAB 3 test installation for me, so it's weird that you can not reproduce on a fresh install. I'll try again myself when I install openHAB 3 from scratch the next time.

eikowagenknecht commented 3 years ago

Broken again (and there is an update available now, I dindn't install it so the tests can continue :-)):

I did not restart the system or even login in the meantime.

mstormi commented 3 years ago

Try if this fixes your issue: in /etc/systemd/system, edit firemotd.{timer,service} In .timer [Timer] section, set Persistent=true RemainAfterElapse=true

In .service [Service] section RemainAfterExit=no

and systemctl daemon-reload and systemctl restart firemotd.timer. Also systemctl status firemotd.service and if running stop it

You can actually set OnCalendar=minutely for a test so you don't have to wait. Or add your own X.timer/X.service files.

Key to look for is what systemctl list-timers outputs for firemotd.timer next run

eikowagenknecht commented 3 years ago

Thank you for taking the time to experiment with me here! This is getting weirder.

I edited the files as you said (Persistent was already on true, so I left that one as it was).

openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.service
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT         LAST                         PASSED      UNIT                         ACTIVATES
Tue 2021-01-26 18:29:07 CET  5h 3min left Tue 2021-01-26 13:22:12 CET  3min 9s ago apt-daily.timer              apt-daily.service
Wed 2021-01-27 00:00:00 CET  10h left     Tue 2021-01-26 00:00:22 CET  13h ago     logrotate.timer              logrotate.service
Wed 2021-01-27 00:00:00 CET  10h left     Tue 2021-01-26 00:00:22 CET  13h ago     man-db.timer                 man-db.service
Wed 2021-01-27 06:53:09 CET  17h left     Tue 2021-01-26 06:38:22 CET  6h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET  22h left     Tue 2021-01-26 12:18:22 CET  1h 6min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a                          n/a          Tue 2021-01-26 13:25:14 CET  7s ago      firemotd.timer               firemotd.service

So apparently nothing changed (yet). Then I set OnCalendar=minutely followed by another service restart:

openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT         LAST                         PASSED      UNIT                         ACTIVATES
Tue 2021-01-26 16:33:36 CET  3h 7min left Tue 2021-01-26 13:25:14 CET  1min 1s ago firemotd.timer               firemotd.service
Wed 2021-01-27 00:00:00 CET  10h left     Tue 2021-01-26 00:00:22 CET  13h ago     logrotate.timer              logrotate.service
Wed 2021-01-27 00:00:00 CET  10h left     Tue 2021-01-26 00:00:22 CET  13h ago     man-db.timer                 man-db.service
Wed 2021-01-27 00:12:22 CET  10h left     Tue 2021-01-26 13:22:12 CET  4min 3s ago apt-daily.timer              apt-daily.service
Wed 2021-01-27 06:09:52 CET  16h left     Tue 2021-01-26 06:38:22 CET  6h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET  22h left     Tue 2021-01-26 12:18:22 CET  1h 7min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

Now it shows up in the list.

But what's weird is the date. See "LEFT: 3h 7min". Currently it's 13:26. I just set it to minutely, so shouldn't that be like... next minute (?)

2 hours later it still is there:

openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT       LAST                         PASSED       UNIT                         ACTIVATES
Tue 2021-01-26 16:33:36 CET  29min left Tue 2021-01-26 13:25:14 CET  2h 38min ago firemotd.timer               firemotd.service
Wed 2021-01-27 00:00:00 CET  7h left    Tue 2021-01-26 00:00:22 CET  16h ago      logrotate.timer              logrotate.service
Wed 2021-01-27 00:00:00 CET  7h left    Tue 2021-01-26 00:00:22 CET  16h ago      man-db.timer                 man-db.service
Wed 2021-01-27 00:12:22 CET  8h left    Tue 2021-01-26 13:22:12 CET  2h 41min ago apt-daily.timer              apt-daily.service
Wed 2021-01-27 06:09:52 CET  14h left   Tue 2021-01-26 06:38:22 CET  9h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET  20h left   Tue 2021-01-26 12:18:22 CET  3h 45min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

... but after the time has passed, it's back to before (= not working):

openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Wed 2021-01-27 00:00:00 CET  5h 11min left Tue 2021-01-26 00:00:22 CET  18h ago      logrotate.timer              logrotate.service
Wed 2021-01-27 00:00:00 CET  5h 11min left Tue 2021-01-26 00:00:22 CET  18h ago      man-db.timer                 man-db.service
Wed 2021-01-27 00:12:22 CET  5h 23min left Tue 2021-01-26 13:22:12 CET  5h 26min ago apt-daily.timer              apt-daily.service
Wed 2021-01-27 06:09:52 CET  11h left      Tue 2021-01-26 06:38:22 CET  12h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2021-01-27 12:18:22 CET  17h left      Tue 2021-01-26 12:18:22 CET  6h ago       systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a                          n/a           Tue 2021-01-26 16:34:12 CET  2h 14min ago firemotd.timer               firemotd.service

Also the count has not been updated at 16:33 apparently:

###############################################################################
###############  pi-openhab3  #################################################
###############################################################################
##        Ip = 192.168.40.41
##   Release = Raspbian GNU/Linux 10 (buster)
##    Kernel = Linux 5.4.83-v7l+
##  Platform = Started Check for Raspberry Pi EEPROM updates.
##    Uptime = 12 day(s). 6:54:23
## CPU Usage = 1.01% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.00, 5m: 0.03, 15m: 0.00
##    Memory = Free: 2.86GB (76%), Used: 0.92GB (24%), Total: 3.78GB
##      Swap = Free: 2.58GB (100%), Used: 0.00GB (0%), Total: 2.58GB
##      Root = Free: 51.43GB (91%), Used: 4.57GB (9%), Total: 58.42GB
##   Updates = 0 apt updates available.
##  Sessions = 2 session(s)
## Processes = 126 running processes of 32768 maximum processes
###############################################################################

                          _   _     _     ____   _
  ___   ___   ___   ___  | | | |   / \   | __ ) (_)  ____   ___
 / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \ | | / _  \ / _ \
| (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )| || (_) || | | |
 \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/ |_| \__|_||_| | |
      |_|                          3.0.0 - Release Build

Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://pi-openhab3:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'

openhabian@pi-openhab3:~ $ sudo apt-get upgrade
[sudo] password for openhabian:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  firmware-atheros firmware-brcm80211 firmware-libertas firmware-misc-nonfree firmware-realtek rpi-eeprom
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.9 MB of archives.
After this operation, 1,584 kB of additional disk space will be used.

mstormi commented 3 years ago

I just set it to minutely, so shouldn't that be like... next minute (?)

For me that worked (although I used an additional service not the existing one). Did you do systemctl daemon-restart ?

Here's again what I use:

[21:52:24] root@openhab:/home/openhabian# cat /etc/systemd/system/firemotd.service
[Unit]
Description=Periodic FireMotD stats regeneration
After=network.target network-online.target

[Service]
Type=oneshot
User=root
Group=root
#RemainAfterExit=yes
RemainAfterExit=no
ExecStart=/usr/local/bin/FireMotD -S -D all &> /dev/null

[Install]
WantedBy=multi-user.target
[21:53:13] root@openhab:/home/openhabian# cat /etc/systemd/system/firemotd.timer
[Unit]
Description=Daily generation of FireMotD stats

[Timer]
OnCalendar=*-*-* 00:00
RandomizedDelaySec=6h
Persistent=true

[Install]
WantedBy=timers.target

eikowagenknecht commented 3 years ago

Yes I did all the restarts as you can see in my second code box. I‘m totally lost why this happens the way it does, especially with the minutely setting that results in some hours.

Did a system reboot now for good measure and now it seems to kindof work, the update count has been updated. But the NEXT date is still way of for my current "minutely" setting (15min ago + 58min left != 1 minute):

openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT                         LEFT       LAST                         PASSED    UNIT                         ACTIVATES
Wed 2021-01-27 00:00:00 CET  42min left Tue 2021-01-26 00:00:22 CET  23h ago   logrotate.timer              logrotate.service
Wed 2021-01-27 00:00:00 CET  42min left Tue 2021-01-26 00:00:22 CET  23h ago   man-db.timer                 man-db.service
Wed 2021-01-27 00:16:14 CET  58min left Tue 2021-01-26 23:02:28 CET  15min ago firemotd.timer               firemotd.service
Wed 2021-01-27 06:49:57 CET  7h left    Tue 2021-01-26 06:38:22 CET  16h ago   apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2021-01-27 09:36:15 CET  10h left   Tue 2021-01-26 23:02:28 CET  15min ago apt-daily.timer              apt-daily.service
Wed 2021-01-27 23:17:26 CET  23h left   Tue 2021-01-26 23:17:26 CET  20s ago   systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

6 timers listed.
Pass --all to see loaded but inactive timers, too.

If it‘s only me who is affected (seems to be that way?) it‘s probably best to write it off as some weird quirk that only happens in special circumstances and not spend too much time on this.

I‘ll reinstall everything with the new image you uploaded some days ago and see if that somehow fixes it.

mstormi commented 3 years ago

ok I'll close this then. You can reopen it if you hit another issue but please make sure it's reproduceable before you open

eikowagenknecht commented 3 years ago

Just for reference.. with the "minutely" setting and a reboot it continues to work. But it only fires about every few hours instead of every minute:

openhabian@pi-openhab3:~ $ systemctl list-timers
NEXT                         LEFT       LAST                         PASSED       UNIT                         ACTIVATES
Wed 2021-01-27 08:59:43 CET  5min left  Wed 2021-01-27 04:32:51 CET  4h 21min ago firemotd.timer               firemotd.service
...

mstormi commented 3 years ago

If I was to make an educated guess: this is because you didn't change RandomizedDelaySec so it's still 6h

openhabian@devpi:/etc/systemd/system $ cat t.timer
[Unit]
Description=generation of FireMotD stats every minute

[Timer]
#OnCalendar=*-*-* 00:00
OnCalendar=minutely
RandomizedDelaySec=0
Persistent=true
RemainAfterElapse=true

[Install]
WantedBy=timers.target

eikowagenknecht commented 3 years ago

You are right. Didn't see the RandomizedDelaySec setting. That of course displays why the delay was longer. So now I set it to "0" (followed by daemon-reload and restart timer) and the first execution after that is just fine on the next full minute... and then it gets stuck again, so everything is back to start:

openhabian@pi-openhab3:/etc/systemd/system $ sudo nano firemotd.timer
[... change RandomizedDelaySec to 0...]
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl daemon-reload
openhabian@pi-openhab3:/etc/systemd/system $ sudo systemctl restart firemotd.timer
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT     LAST                         PASSED  UNIT                         ACTIVATES
Wed 2021-01-27 16:23:00 CET  27s left Wed 2021-01-27 16:22:23 CET  9s ago  firemotd.timer               firemotd.service
[...1 minute later...]
openhabian@pi-openhab3:/etc/systemd/system $ systemctl list-timers
NEXT                         LEFT     LAST                         PASSED   UNIT                         ACTIVATES
n/a                          n/a      Wed 2021-01-27 16:23:38 CET  52ms ago firemotd.timer               firemotd.service

mstormi commented 3 years ago

also right before the next full minute ? It's n/a while running.

eikowagenknecht commented 3 years ago

Ok, i checked this every few seconds now and it seems it's running (in n/a state) from :00 to ~:20 and then scheduled again to run the next full minute. Conclusion: Your proposed changes (

in /etc/systemd/system, edit firemotd.{timer,service} In .timer [Timer] section, set RemainAfterElapse=true

In .service [Service] section RemainAfterExit=no

and systemctl daemon-reload and systemctl restart firemotd.timer

) followed by a complete system restart seem to have fixed it.

For me it seems plausible, quoting the official documentation here:

Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case. Due to this, services with RemainAfterExit= set (which stay around continuously even after the service's main process exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and then stay around forever.

Also RemainAfterElapse defaults to true, so it can probably be left out.

Maybe it's worth including this in the next distribution, since it fixed it for me and doesn't cause other side effects for you (as far as I understand)?

mstormi commented 3 years ago

Maybe it's worth including this in the next distribution, since it fixed it for me and doesn't cause other side effects for you (as far as I understand)?

It's already in

openhab / openhabian

[OH3] motd doesn't show correct update count #1410

Issue information:

System information: