cron.daily/systemd message after reboot

Having issues with your DietPi installation or found a bug? Post it here.
Post Reply
ecognito
Posts: 1
Joined: Tue Jun 01, 2021 2:29 am

cron.daily/systemd message after reboot

Post by ecognito »

After I reboot my dietpi, the cron.daily task always emits the following email:

Code: Select all

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?
User avatar
Joulinar
Posts: 4783
Joined: Sat Nov 16, 2019 12:49 am

Re: cron.daily/systemd message after reboot

Post by Joulinar »

Hi,

I guess it's not a critical issue as long as the time sync success. You can check this by running

Code: Select all

systemctl status systemd-timesyncd.service


@MichaIng
can you have a look pls
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
User avatar
MichaIng
Site Admin
Posts: 2987
Joined: Sat Nov 18, 2017 6:21 pm

Re: cron.daily/systemd message after reboot

Post by MichaIng »

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:

Code: Select all

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:

Code: Select all

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.
Post Reply