After I reboot my dietpi, the cron.daily task always emits the following email:
Subject: Cron <root@myhost> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/dietpi:
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Running the recommended “systemctl daemon-reload” does fix the issue, but only until the next reboot.
Any ideas?
Hi,
I guess it’s not a critical issue as long as the time sync success. You can check this by running
systemctl status systemd-timesyncd.service
MichaIng
can you have a look pls
While on reboot, of course all systemd units are reloaded, as whenever an APT install/upgrade ships a systemd unit, I observe this error by times and never found out how this is the case, especially since timestamps on that systemd unit stay untouched. It can be safely ignored.
If you want to debug, you can start checking kernel logs for errors and verify/compare system time and timestamps of the unit file, whether it is all as expected:
dmesg -l emerg,alert,crit,err
systemctl status systemd-timesyncd
ls -l /lib/systemd/system/systemd-timesyncd.service
date
And to trigger the warning without overhead:
systemctl restart systemd-timesyncd
I’m not sure how systemd derives whether a unit has changed or not, without either a database to store mtimes or by comparing timestamps of last reload and current mtime. E.g. when on first reload, the system time is way in the past, earlier than the units mtime, then the time is synced, then on next reload systemd sees an mtime that is newer than the timestamp of the last reload, or so.