How to check if the clock has been synchronised/set ?

Hello all,

Is there a way to check if the Pi's date and time has been either synchronised with an NTP server or has been set otherwise (manually or programmatically) ?

I'm asking as I would like to do something with filetimes (comparing them to backup files), and those are only meaningfull with a correctly set date and time.

Regards, Rudy Wieser

Reply to
R.Wieser
Loading thread data ...

timedatectl

--

Knute Johnson
Reply to
Knute Johnson

Knute,

Thanks. That seems to take care of the "synchronised" part of my question. Any idea bout the "manual" part ?

The "manual" part is important to me for when I run the Pi without having it connected to the internet - and I (currently) thus need to set the date/time manually.

Regards, Rudy Wieser

Reply to
R.Wieser

How about using ntp plus a cheap usb gps dongle to keep the time? Mine seems OK to within a few tens of msec (running freebsd when I tested, but linux shouldn't be any different).

--
Mike Scott 
Harlow, England
Reply to
Mike Scott

Mike,

:-) I already have a good (precise) RTC here which I could just tell raspbian to use. But thats not the problem I currently want to solve. Seeing if /any/ of the clock-setting/synchronisation methods has been applied is.

The target is to prohibit a program (python script in this case) from doing filetime comparisions when the clock cannot be depended upon. Like in your case before the dongle has been able to synchronise to the gps sattelites.

Thanks for the suggestion though.

Regards, Rudy Wieser

Reply to
R.Wieser

Ok I've not been following closely, it's been too tortuous and tangential, but surely all you need to do is read the RTC and the linux system time and compare them. I see you think you have a "precise" realtime clock - do you know how well it keeps time?

Some years back, I had an early ARM board with Linux and and an RTC. On boot the system read the RTC to set the kernel clock, and on shutdown it set the RTC to the current kernel system time. The kernel system time wasn't too accurate - it drifted. Mind you the RTC wasn't super brilliant either. I rembember using adjtimex (you may have to install it) to adjust the parameters of the kernel system clock to make it as accurate as I needed, given my environment (temp etc). The details escape me now, the grey cells aren't what they were. but I compared the board time to another computer running NTP to get them as close as possible. Took some time.

Of course if you insist on wanting to do all this in a single python program I can't help, sorry, I haven't learnt python. I could have done it all in C, which I can progrma in, but why bother when there are utilities already made for doing things.

Jim

Reply to
Jim Jackson

Jim,

Why ? If I actually can read the RTC than all I need to do is write it into the Pi's clock and be done with it.

The thing is that the Pi can be given its time from a number of sources, and my approach is to ask the clock itself (where a single check should to), instead of trying to go thru all the possible sources.

Its a DS3231, which uses a temperature-controlled crystal to keep it as precise as possible.

But its not the the Pi's clock drift that bothers me. Its that, without an internet connection and being shut down and rebooted (much) later, it could be running with yesterdays (or even before) date and time.

... Though I just realized that if the clock is saved on shutdown and reloaded when its boots again (as I seem to remember) the filetimes not being the actual time doesn't really interfere with being able to compare them. But that doesn't mean that I would not rather have them reflect the actual time. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

Am 05.11.2019 um 15:30 schrieb R.Wieser:

maybe help by this:

formatting link

sorry, its german.

Reply to
Helmut Harnisch

No it's under your control as the sysadmin of the actual pi you are using.

I do think you are making a real meal out this :-0

But it's you time and energy.

Reply to
Jim Jackson

You do need a piece of C code, run as root or suid root, reading the external hardware clock and setting the internal one with a simple system call.

Your problem is that the setting of system time needs root privileges.

--

-TV
Reply to
Tauno Voipio

Have you had a look at: ?

--

-TV
Reply to
Tauno Voipio

Google Translate produces very good English. The only thing that *may* not be right is the advice in "Testing the Configuration" which says "The easiest way to check whether the RTC has worked is to switch off the device and then reboot it for a few hours." I wonder whether it should say "The easiest way to check whether the RTC has worked is to switch off the device for a few hours and then reboot it." Google's version implies that you got through shutdown/reboot cycles for a couple of hours ;-) That's Google's mistake: the German gets it right, as far as I can tell from my O level German.

Reply to
NY

Helmut,

The language is not the problem (I'm your west-side neighbour), but you're trying to solve a problem I do not have. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

Jim,

That doesn't change anything to what I said. There is ntp, an rtc, and someone already suggested an gps dongle. And than there are at few others that have not been named yet.

Lol! That was what I was thinking - you guys suggesting all kinds of "lets get that thing synchronised" solutions /when I'm not asking for that/ ...

Regards, Rudy Wieser

Reply to
R.Wieser

Tauno,

1) Thats an answer to a question I never asked. :-(

2) I already did something like that - a year or so ago.

3) Just this week I wrote pretty much that, using python.

4)

Nope, not one of my problems. Not now, not in 2) and not in 3) either.

Now, do you have /any/ idea how to detect that the clock has been written to after the last time the Pi has been switched on ? As *thats* the problem I'm currently trying to solve - as shown in the title of this message.

Regards, Rudy Wieser

Reply to
R.Wieser

Well isn't that how a real computer works.

The startup scripts read the hardware clock (RTC) and set the system time. (hwclock --hctosys) When the network is up, ntpd is started to keep the system clock in sync. (Or another clock radio, gps etc.) On shutdown, the hardware clock is adjusted (if necessary) with the current system time - assumed to be correct because of ntpd or similar (hwclock --systohc).

You should disable the fake-hwclock (distributed with Raspbian and derivatives) service and use the hwclock service.

Your approach is wrong if you have a real hardware clock - see above.

--

Chris Elvidge, England
Reply to
Chris Elvidge

  1. Try all of the different ways you have of setting the clock - GPS, NTP, manual, whatever.
  2. Look in the system logs to see what message gets logged for each change. For example I see "systemd-timesyncd[...]: Synchronized to time server for the first time" for a normal internet-connected boot.
  3. Now if you ever see one of those messages again in the log, you'll know that the time has been changed.
--
Dave
Reply to
Dave

Dave,

Thanks for the logfile suggestion, I didn't think of that (still to much a Windows mindset I'm afraid). I'll see what I can find.

... Though I had hoped to be able to check the clock itself (in some way or another), as that is /the/ bottleneck for (any possible) changes ...

Regards, Rudy Wieser

Reply to
R.Wieser

Chris,

And why would I want to convert my Pi into a "real computer" ? I've already got one.

If I would do what you say - demand actually - than /your/ problem would be solved, not mine. And as I do not know you and as such do not need to humor you, why should I do that ?

But, seeing that you are hell-bent on solving /your/ problem by making my RTC a permanent fixture to /my/ Pi (which can only be done with wires sticking out and a good glob of hot-glue - something you didn't even consider) I don't think it makes any sense to continue our conversation. As such, goodbye.

Regards, Rudy Wieser

Reply to
R.Wieser

But I don't have a problem.

--

Chris Elvidge, England
Reply to
Chris Elvidge

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.