What controls time on the Pi?

[talz]

I'm running Raspbian 10.
I'm trying to figure out all the different things that change the system clock at boot, and there appear to be a LOT of them.

So far, this is what I've been able to figure out:

The system comes pre-configured with systemd-timesyncd, which tries to get the current time over the internet at boot.
Even if you disable that with:

Code: Select all

systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd

and run

Code: Select all

date --set "SEP 01 2000 00:00:00"

At boot, something still fixes the time, or at least tries to.

The most likely culprit is /etc/init.d/fake-hwclock, which systemd turns into a service dynamically using systemd-sysv-generator.
/etc/init.d/fake-hwclock uses /sbin/fake-hwclock to save the time at shutdown, and restore it at startup. It ensures that even if the clock isn't perfectly accurate, at least it won't appear to go backwards. Presumably this happens before NTP, and works even if internet is not available (unlike NTP). Makes sense.

Removing /etc/init.d/fake-hwclock, setting the date to the year 2000, and rebooting, something still fixes the clock.
Removing /sbin/fake-hwclock didn't help either.

Then, there's another init.d script - hwclock.sh. Not really sure what it does, but it's clearly time-related, so I got rid of that too. That didn't help either. A reboot still restores the clock to a fairly-recent date.

How many layers does one device need? What else is restoring the system clock at boot?

[tahunasky]

From what I understand.
The pi gets the date/time from the internet.
If no internet connection will see what the last date/time was (i think it must be written to file somewhere) and guess the date time from that using fake-hwclock.
hwclock.sh I am guessing is use when there is a RTC (real time clock) connected to the pi.

I use a RTC on my pi's mostly because I do not have a fixed line internet connection, and use my phone as a hotspot so if the phone is not around there is no internet connection to get time from. When I log solar production and power usage i want a reliable time/date.
I also use the RTC for waking up the pi at predetermined times.

[talz]

From what I understand.
The pi gets the date/time from the internet.

It uses systemd-timesyncd. I already covered that.

If no internet connection will see what the last date/time was (i think it must be written to file somewhere) and guess the date time from that using fake-hwclock.

Ya - I covered that too. Did you even read my post?

hwclock.sh I am guessing is use when there is a RTC (real time clock) connected to the pi.

From what little I know about it from looking at the source, that sounds right, which is why I didn't dig too deep. I don't have an RTC, so this doesn't effect me.

I use a RTC on my pi's mostly because I do not have a fixed line internet connection, and use my phone as a hotspot so if the phone is not around there is no internet connection to get time from. When I log solar production and power usage i want a reliable time/date.
I also use the RTC for waking up the pi at predetermined times.

Thanks - I know what an RTC is for. That doesn't help.

Anyone with anything definitive to say, rather than re-stating what has already been covered in an uncertain-of-oneself tone?

[DougieLawson]

I had a look at a system running RaspiOS that I rebuilt on 9th Jan.

There's only /etc/init.d/fake-hwclock /etc/init.d/hwclock /sbin/fake-hwclock (which is a shell script) /sbin/hwclock (which is an executable for systems with an rtc) on an install of plain RaspiOS Buster. I've eliminated the systemd timesync stuff as all of my systems use good old-fashioned ntpd so they're all synced to one Raspberry that has an RTC and is usually sync'd to an external NTP server.

Since you've done all the pieces with fake-hwclock that can't be doing it. Easiest way to be sure is to disable /sbin/fake-hwclock by changing (or by creating a new script that simply has the exit command if you've un-installed fake-hwclock).

Code: Select all

#!/bin/sh
#
# Trivial script to load/save current contents of the kernel clock
# from/to a file. Helpful as a *bootstrap* clock on machines where
# there isn't a useful RTC driver (e.g. on development boards). Using
# NTP is still recommended on these machines to get to real time sync
# once more of the system is up and running.
#
# Copyright 2012-2016 Steve McIntyre <93sam@debian.org>
#
# License: GPLv2, see COPYING

if [ "$FILE"x = ""x ] ; then
    FILE=/etc/fake-hwclock.data
fi

to

Code: Select all

#!/bin/sh
#
# Trivial script to load/save current contents of the kernel clock
# from/to a file. Helpful as a *bootstrap* clock on machines where
# there isn't a useful RTC driver (e.g. on development boards). Using
# NTP is still recommended on these machines to get to real time sync
# once more of the system is up and running.
#
# Copyright 2012-2016 Steve McIntyre <93sam@debian.org>
#
# License: GPLv2, see COPYING
exit 20

if [ "$FILE"x = ""x ] ; then
    FILE=/etc/fake-hwclock.data
fi

Then set the time to any value other than now or 2016-04-15 00:00:00.
echo "2018-09-04 12:30:30" > /etc/fake-hwclock.data
so you'd know if that has been used to set the clock and after the system has been booted that it hasn't re-written the fake-hwclock.data file.

[talz]

Thanks for looking into it Dougie.

I moved /etc/init.d/fake-hwclock and /etc/init.d/hwclock out of that dir (essentially deleting it), and tried replacing /sbin/fake-hwclock with a shell script that does nothing. Something still resets the system clock at boot from the year 2000 that I set it to with:

Code: Select all

date --set "SEP 01 2000 00:00:00"

to 2019.

Before removing fake-hwclock, the system clock was getting reset to today, which makes sense, since it had that written down in a file someplace. Not sure where it got 2019 from, or what changes it to that, now that fake-hwclock is disabled. Something else must be doing something with the system clock at boot.

Update: I tried to combine everything. I:

• Made sure /etc/init.d/fake-hwclock was removed
• Made sure /etc/init.d/hwclock.sh was removed (although it shouldn't do anything)
• Made sure /sbin/fake-hwclock was removed
• Set current date to 2000 with "date --set "SEP 01 2000 00:00:00"
• Set /etc/fake-hwclock.data to 2000-09-01 00:10:30 with "echo "2000-09-01 00:10:30" > /etc/fake-hwclock.data"

After a reboot, the "date" command shows the time as Thu Feb 14 03:12:22 MST 2019. Linux must really like Valentine's Day.

[DougieLawson]

Has your SDCard gone read-only?

[talz]

Nope. SD Card seems fine. /etc/fake-hwclock.data still has 2000-09-01 00:10:30 after the reboot, just like I wrote to it. systemd-timesyncd is still disabled. The init.d files, and the binary are all still gone too, as expected.

[DougieLawson]

Nope. SD Card seems fine. /etc/fake-hwclock.data still has 2000-09-01 00:10:30 after the reboot, just like I wrote to it. systemd-timesyncd is still disabled. The init.d files, and the binary are all still gone too, as expected.

That also tells us it's not fake-hwclock.

Is this a lite system, a desktop system or a desktop with extras system?
Have you installed anything like k8s or docker or such-like?

[talz]

2020-08-20-raspios-buster-armhf-lite.img

I did install ntp, which replaces systemd-timesyncd, but that is disabled as well.
It doesn't appear to be any NTP services doing this, or the time would be accurate, instead of coming up as 2019.
No docker.
Not sure what k8s is, so I guess not.

[DougieLawson]

k8s is Kubernetes (shortened by removing 8 letters from the middle).

On my Lite system all I did was install ntpd, run sudo timedatectl set-ntp on, sudo systemctl enable ntp and disable systemd-timesyncd. Nothing else, no mucking about disabling fake-hwclock. Job done.

[talz]

When I started this post, I was trying to learn about all the different things that effect the system clock so I could accomplish a particular goal.
Since then, I've pretty much accomplished the goal I was after, but I'm still very much curious what keeps resetting the system clock from 2000 to 2019, as I clearly don't have the full picture of all the parts that effect the system clock, and it's bugging me.

[DougieLawson]

What happens if you start with a fresh install of RaspiOS (on another SDCard) and do nothing with it except attempt to get the clock working the way you want it?
It's got to be related to something you've done or something you've installed.

So get RaspiOS running, get the clock working the way you want it. Then add in each of the components you need checking things are working at each step of the way.

[bls]

Since systemd-timesyncd was mentioned as being less than optimal a couple of times, I'll throw in a vote for it on "time slave systems" (systems that get the time from somewhere else on the LAN). I set up my systems with /etc/systemd/timesyncd.conf having the following contents:

Code: Select all

[Time]
# If you use this, don't forget to modifty the NTP address to be your local ntpd/chronyd server
NTP=192.168.92.3
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

This way, all my "time slave systems" get their time from the same host, which is either running chronyd or ntp (I've switched a few times). I haven't looked to see which is smaller, but systemd-timesyncd doesn't require installing any additional packages, and is easy enough to configure in time slave mode.

[achrn]

When I started this post, I was trying to learn about all the different things that effect the system clock so I could accomplish a particular goal.
Since then, I've pretty much accomplished the goal I was after, but I'm still very much curious what keeps resetting the system clock from 2000 to 2019, as I clearly don't have the full picture of all the parts that effect the system clock, and it's bugging me.

If you manually set a date that's later than valentines day, does it stick with your manually set or also get put back to valentines day? Not that this will help establish what is doing it, but it might be another data point.

[ganzgustav22]

Not sure if it helps, but I've just disabled systemd-timesyncd (in fact it was already disabled before) and added "exit 0" at the top of /sbin/fake-hwclock.

After reboot I got:
Thu 14 Feb 11:12:45 CET 2019

When searching the web for "Linux time valentines day" I stumbled across this:
https://fsfe.org/activities/ilovefs/index.en.html

Seems like somebody thought it would be a good idea to hardcode that date somewhere. My gut feeling tells me it was Mr. Poettering, but I don't know.

[ganzgustav22]

Yup. It was Mr. Poettering:

[ 0.927059] systemd[1]: System time before build time, advancing clock.

(I bet a hundred bucks, that when you google for this logline, you'll find some issue on Github where people reported this behaviour and Mr. Poettering came up with dozens of stupid reasons why this systemd behaviour totally makes sense)

[talz]

https://github.com/systemd/systemd/issues/15320

Somebody owes ganzgustav22 $100

So it seems like systemd-timesyncd and fake-hwclock are the main things that set system time. Without those, as long as the system clock isn't set to a date before the systemd build time, nothing else touches it.

If you happen to have an RTC, hwclock may also try to set system time based on RTC, which for a regular raspberry pi without an external RTC doesn't apply.

Thanks guys.