Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

chrony date months off

58 views
Skip to first unread message

gene heskett

unread,
Jan 31, 2024, 5:40:07 AM1/31/24
to
How do I setup /etc/chrony/chrony.conf so it slams the system clock to
the current time on the first cycle as its rebooting?
There was 20 yeas back, an ntpdate command that would do that.
Now it appears to conflict with the other client/servers

Thanks

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

to...@tuxteam.de

unread,
Jan 31, 2024, 6:00:06 AM1/31/24
to
On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
> current time on the first cycle as its rebooting?
> There was 20 yeas back, an ntpdate command that would do that.
> Now it appears to conflict with the other client/servers

I think you want "maxstep". It's in the man page chrony.conf(5).

But if the time is "months off" perhaps you've got another problem
to fix first?

You wouldn't want chrony to slam your clock just because its only
reachable server runs amok. Just sayin'.

Cheers
--
t
signature.asc

Max Nikulin

unread,
Jan 31, 2024, 7:20:07 AM1/31/24
to
On 31/01/2024 17:54, to...@tuxteam.de wrote:
> I think you want "maxstep". It's in the man page chrony.conf(5).
>
> But if the time is "months off" perhaps you've got another problem
> to fix first?

I think, the problem is no RTC on some *pi board, certainly chrony out
of box setup is not ready to such environment and its solution is not
maxstep.

Gene, are you going to complain again that some package has no man pages?

didar

unread,
Jan 31, 2024, 8:40:06 AM1/31/24
to
On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
> current time on the first cycle as its rebooting?
> There was 20 yeas back, an ntpdate command that would do that.
> Now it appears to conflict with the other client/servers

You can use "rdate" (openrdate) as quick fix like `ntpdate'. I resort to using
it inside my virtual machines on my laptop when it wakes up from hibernation.

I use chrony on my production MTAs on the internet though.

--
Regards,
Didar

Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Generated by Signify v1.14 (http://www.debian.org/)

John Hasler

unread,
Jan 31, 2024, 9:00:10 AM1/31/24
to
Gene writes:
> How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> the current time on the first cycle as its rebooting?

initstepslew

man chrony.conf
--
John Hasler
jo...@sugarbit.com
Elmwood, WI USA

Greg Wooledge

unread,
Jan 31, 2024, 9:10:06 AM1/31/24
to
On Wed, Jan 31, 2024 at 07:53:01AM -0600, John Hasler wrote:
> Gene writes:
> > How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> > the current time on the first cycle as its rebooting?
>
> initstepslew
>
> man chrony.conf

Debian 12 has chrony 4.3, and in *that* version of the man page, it
says initstepslew is deprecated in favor of makestep.

https://chrony-project.org/doc/4.3/chrony.conf.html#makestep

gene heskett

unread,
Jan 31, 2024, 9:50:06 AM1/31/24
to
On 1/31/24 07:13, Max Nikulin wrote:
> On 31/01/2024 17:54, to...@tuxteam.de wrote:
>> I think you want "maxstep". It's in the man page chrony.conf(5).
>>
>> But if the time is "months off" perhaps you've got another problem
>> to fix first?
Well, I do have other probs with that machine, mostly with the physicsl
config of the BTT Octopus Pro 3dprinter control card its running, but
that is not os related, it just a detail I have fixed on all the other
machines.

> I think, the problem is no RTC on some *pi board, certainly chrony out
> of box setup is not ready to such environment and its solution is not
> maxstep.
>
> Gene, are you going to complain again that some package has no man pages?

Mope. Thanks Max

John Hasler

unread,
Jan 31, 2024, 10:00:07 AM1/31/24
to
Max Nikulin wrote:
> I think, the problem is no RTC on some *pi board, certainly chrony out of
> box setup is not ready to such environment and its solution is not
> maxstep.

That's what makestep (initstepslew now being deprecated) is for.

gene heskett

unread,
Jan 31, 2024, 10:30:08 AM1/31/24
to
On 1/31/24 08:53, John Hasler wrote:
> Gene writes:
>> How do I setup /etc/chrony/chrony.conf so it slams the system clock to
>> the current time on the first cycle as its rebooting?
>
> initstepslew
>
> man chrony.conf

deprecated in favor of makestep, and did not work, John.

Thanks, John

Greg Wooledge

unread,
Jan 31, 2024, 10:50:08 AM1/31/24
to
On Wed, Jan 31, 2024 at 10:25:40AM -0500, gene heskett wrote:
> On 1/31/24 08:53, John Hasler wrote:
> > Gene writes:
> > > How do I setup /etc/chrony/chrony.conf so it slams the system clock to
> > > the current time on the first cycle as its rebooting?
> >
> > initstepslew
> >
> > man chrony.conf
>
> deprecated in favor of makestep, and did not work, John.

*sigh*

How many times do we have to say it? When something goes wrong, don't
simply say "it didn't work". Give the *details*.

What changes did you make to files? What do the files look like now?

What commands did you run?

What output did you get?

What output did you *expect* to get?

What other relevant details can you supply? (The identities and
configurations of the NTP servers that chrony is expected to use, for
example.)

gene heskett

unread,
Jan 31, 2024, 1:00:07 PM1/31/24
to
On 1/31/24 10:44, Greg Wooledge wrote:
> On Wed, Jan 31, 2024 at 10:25:40AM -0500, gene heskett wrote:
>> On 1/31/24 08:53, John Hasler wrote:
>>> Gene writes:
>>>> How do I setup /etc/chrony/chrony.conf so it slams the system clock to
>>>> the current time on the first cycle as its rebooting?
>>>
>>> initstepslew
>>>
>>> man chrony.conf
>>
>> deprecated in favor of makestep, and did not work, John.
>
> *sigh*
>
> How many times do we have to say it? When something goes wrong, don't
> simply say "it didn't work". Give the *details*.
>
> What changes did you make to files? What do the files look like now?
gene@bpi51e5p:/etc/chrony$ cat chrony.conf
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries
being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP:
#104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp
sourcedir /etc/chrony/sources.d

# This directive specify the location of the file containing ID/key
pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100000.0
initstepslew 30 192.168.71.3
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile'
directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is
larger than
# one second, but only in the first three clock updates.
makestep 1 3000

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapsectz right/UTC
gene@bpi51e5p:/etc/chrony$

Now, the file in /etc/chrony/sources.d:
gene@bpi51e5p:/etc/chrony/sources.d$ cat local-ntp-server.sources
server 192.168.71.3 iburst
gene@bpi51e5p:/etc/chrony/sources.d$

>
> What commands did you run?
>
6 of one half a dozen of the other
gene@bpi51e5p:/etc/init.d$ sudo ./chrony status
[sudo] password for gene:
× chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled;
vendor preset: enabled)
Active: failed (Result: protocol) since Sat 2023-12-30 03:15:44
EST; 2h 12min ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 1908 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh
$DAEMON_OPTS (code=exited, status=0/SUCCESS)
CPU: 158ms

Dec 30 03:15:31 bpi51e5p chronyd[1936]: chronyd version 4.2 starting
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGN…6 -DEBUG)
Dec 30 03:15:31 bpi51e5p chronyd[1936]: Frequency -20.055 +/- 0.010 ppm
read from /var/lib/chrony/chrony.drift
Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to
obtain leap second data
Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1)
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936
does not exist or is a zombie.
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result
'protocol'.
Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP
client/server.
Hint: Some lines were ellipsized, use -l to show in full.
gene@bpi51e5p:/etc/init.d$

or

gene@bpi51e5p:/etc/init.d$ sudo systemctl status chrony.service
× chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled;
vendor preset: enabled)
Active: failed (Result: protocol) since Sat 2023-12-30 03:15:44
EST; 2h 13min ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 1908 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh
$DAEMON_OPTS (code=exited, status=0/SUCCESS)
CPU: 158ms

Dec 30 03:15:31 bpi51e5p chronyd[1936]: chronyd version 4.2 starting
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCD>
Dec 30 03:15:31 bpi51e5p chronyd[1936]: Frequency -20.055 +/- 0.010 ppm
read from /var/lib/chrony/chrony.drift
Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to
obtain leap second data
Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1)
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936
does not exist or is a zombie.
Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result
'protocol'.
Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP
client/server.

> What output did you get?
The time as reported by "date":
gene@bpi51e5p:~$ date
Sat Dec 30 05:30:58 AM EST 2023
gene@bpi51e5p:~$
gene@coyote:~$ date
Wed Jan 31 12:38:16 EST 2024
gene@coyote:~$


>
> What output did you *expect* to get?

The time reported by date here about a minute later:
gene@coyote:~$ date
Wed Jan 31 12:38:16 EST 2024
gene@coyote:~$


> What other relevant details can you supply? (The identities and
> configurations of the NTP servers that chrony is expected to use, for
> example.)
>
There was an /etc/chrony/chrony.conf file, but no chrmy installed I had
to install it fresh, which is puzzling. That was an earlier install now
uptodate:
Linux bpi51e5p 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19
UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
gene@bpi51e5p:/etc$ cat issue
Armbian 23.11.1 jammy \l
.
Did I miss anything with this wall of text? If there's still something
missing, id it and I'll see if it exists and copy/paste it.

Cheers, Greg, Gene Heskett, CET.

Greg Wooledge

unread,
Jan 31, 2024, 1:20:06 PM1/31/24
to
On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote:
[...]
> # Stop bad estimates upsetting machine clock.
> maxupdateskew 100000.0
> initstepslew 30 192.168.71.3
> # This directive enables kernel synchronisation (every 11 minutes) of the
> # real-time clock. Note that it can’t be used along with the 'rtcfile'
> directive.
> rtcsync
>
> # Step the system clock instead of slewing it if the adjustment is larger
> than
> # one second, but only in the first three clock updates.
> makestep 1 3000

I've never used chrony, so all I know about it is what I've gleaned
from skimming the chrony.conf page, from Google search results, and
from things that people have said here.

With that in mind, I don't know what happens if you've got both
initstepslew *and* makestep in the same conf file. I would imagine
you only want one of them.

> Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to obtain
> leap second data
> Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1)
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3

That IP address clearly came from your initstepslew line. Is there an
NTP service running on that host? If so, is it synchronized? And does
it permit client requests (from bpi51e5p)?

> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 does
> not exist or is a zombie.
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result
> 'protocol'.
> Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP
> client/server.

This appears to be important. It's failing to start, which means it's
not setting the clock, or doing anything else. You'll need to figure
out why it's not starting. Perhaps it's *just* the fact that it can't
contact an NTP service at 192.168.71.3. Or maybe there's more to the
story. I don't know.

gene heskett

unread,
Jan 31, 2024, 4:30:05 PM1/31/24
to
On 1/31/24 13:19, Greg Wooledge wrote:
> On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote:
> [...]
>> # Stop bad estimates upsetting machine clock.
>> maxupdateskew 100000.0
>> initstepslew 30 192.168.71.3
>> # This directive enables kernel synchronisation (every 11 minutes) of the
>> # real-time clock. Note that it can’t be used along with the 'rtcfile'
>> directive.
>> rtcsync

I'll comment that line
>> # Step the system clock instead of slewing it if the adjustment is larger
>> than
>> # one second, but only in the first three clock updates.
>> makestep 1 3000
I had tried 30, and it did it about that many time ack the tcpdump log
I'm tracking. And I'll put the 300 back in, that ack the tcpdump
monitor seemed to effective. but I've not found in the docs, anything
that will modify how far the step will change it, The first arg is one
second.

chrony seems to be the fave method for the arm64's but I have had
better luck using ntpsec without the security on all other wintel
machines. Its ntpsec I'm using on this machine to be a stratum 2 server
for the rest of my local net. So that's what all the other local
machines see. timedatectl bombs when asked to set-time, regardless of
how many space separated arguments is says too many arguments. Aha! the
time argument needs single quotes around it! The help screen is wrong
but the man page says " ". So I have it now set for about 4 hours ago.
Now about 5 seconds off, but its not querying my server. More man page
perusal. I am getting the impression that timedatctl ultimately uses he
first time service it can find, and while I have the clock sey pretty
close, it nat offer ntp until there is an available ntp client, and I
used apt to purge both chrony and ntpsec. So I;ll reinstall ntpsec. Done

Then I went clear around the mulberry tree and copied (because my sshnet
mounts of all these machine is as a user) the
/sshnet/go704/etc/ntpsec/ntp.conf to my home dir on that box, then fired
up a user mc and copied that file from /sshnet/go704/home/gene to
/sshnet/bpi51/home/gene.
went to a different workspace, fired up a sudo mc, copied that file to
that machines /etc/ntpsec dir, then fixed the perms back to 0600.

Then restarted ntpsec by stopping it, then starting it again so it would
read the new file. Then:

gene@bpi51e5p:~$ timedatectl status
Local time: Wed 2024-01-31 15:40:13 EST
Universal time: Wed 2024-01-31 20:40:13 UTC
RTC time: Wed 2024-01-31 20:40:13
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
NTP service: n/a
RTC in local TZ: no

And my tcpdump trace here?:
15:51:01.235371 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp:
NTPv4, Client, length 48
15:51:01.235523 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp:
NTPv4, Server, length 48
15:52:06.236633 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp:
NTPv4, Client, length 48
15:52:06.236701 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp:
NTPv4, Server, length 48

IOW, its working. And I found another off by about an hour, so I copied
that same file it it, problem solved.

Now, I still have more cats to skin but solving those two problems will
help. Now I can get back to the real problem. Lack of docs to make a
TMC-2209, a very common motor driver in the stepstick category, work in
the uart interface mode in a BTT octopus Pro controller cards driver
sockets 2, 3 & 4. Add about 12 jumpers and put them back in
step/dir/enable mode is the next test. That's going to take some coffee
I haven't made yet today.

Thanks for the nudge to make me think, Greg, take care & stay well.

Cheers, Gene Heskett, CET.

hw

unread,
Jan 31, 2024, 4:40:06 PM1/31/24
to
On Wed, 2024-01-31 at 12:56 -0500, gene heskett wrote:
> [...]
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew
> Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936
> does not exist or is a zombie.
> Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result
> 'protocol'.

Perhaps uncomment one/some of the pool address(es) in its config to
allow chrony to find a suitable server.

Steve McIntyre

unread,
Jan 31, 2024, 4:50:06 PM1/31/24
to
Darac Marjal <maili...@darac.org.uk> wrote:
>
>The script works like this: if the root device is specified on the
>kernel command line AND the word "fixrtc" is  specified, then get the
>time that the root file system was last mounted. The script then uses
>"date" to set the clock to that date stamp.
>
>I assume that the idea is that, rather than having the clock start at
>1970, it's better to start it at, say, yesterday. You've still got quite
>a lot of slewing to do if you connect to NTP, but at least there's a
>chance that you can verify certificates etc.

I also wrote fake-hwclock (packaged in Debian) for this kind of reason.

--
Steve McIntyre, Cambridge, UK. st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Max Nikulin

unread,
Jan 31, 2024, 10:00:07 PM1/31/24
to
On 31/01/2024 20:24, didar wrote:
> On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote:
>> How do I setup /etc/chrony/chrony.conf so it slams the system clock to the
>> current time on the first cycle as its rebooting?
>> There was 20 yeas back, an ntpdate command that would do that.
>
> You can use "rdate" (openrdate) as quick fix like `ntpdate'.
Is there a real reason to install an extra package if chrony provides a
tool similar to ntpdate?

If I recall it right, the reason why chrony appeared here was just

$ man timesyncd
No manual entry for timesyncd

If it is that box with armbian modified by a Chinese 3d printer vendor
then I am surprised that, intended for boards without RTC, it does not
have proper NTP setup out of the box. Despite I expect arbitrary
peculiarities in this kind of a Linux distribution, I still believe that
NTP troubles were caused by user actions.

gene heskett

unread,
Feb 1, 2024, 12:30:06 AM2/1/24
to
I'd argue that in the bigger picture, the edge distributions, some of
which are one man operations or very close to it, like armbian, know
these are often used in offline environments where it is not that
important. But the minute you plug in the cat-# it is a different story.
We are doing things with baby arm's that would normally take a 6 core i5
to do, but doing it 1/4 as fast and on only 5% of the power. That fast
enough to get the job done, but lack of attention to what s/b just works
stuff says bad code is still bad code. I'm finally understanding things
the man pages will never tell you, about interdependentcy's. Once you
begin to understand how timedatectl actually works, it all falls into
place and just works.

My goal in much of this is to reduce my visibility on the net, so I now
have only a one machine loading at pool.debian.org, instead of 5, soon
to be 7. This machine has the power to be a server, so it now has a
dhcpd server, specially configured to answer only one mac address, just
to give an X-Max3 printer its hostname and net address. I am also an
ntp server, stratum 2, for the use of the rest of the machines on my
local net. Yet each and every one has full net access. With dd-wrt
standing guard. I have only one registered address you can ping. My
original 20 gigabyte web page is down, left with the death of those 2
seacrate 2T's in less than 30 days service about 2 days apart. But when
it comes back it will be to support a woodworkers big bench vice I have
designed, the screw is about 50mm by 500mm in hard maple, buttress
thread, the reminder of it is printed in PETG for its resilience.
Stronger grip than anything you can get on ebay. With one bigger
printer, it takes about a day on the milling machine for the screw, but
2+ weeks for the rest of the parts for a single screw. That's why the
push to build a (presently 3 bigger printers, was 4 till I lost the
printheads umbilical cable on a creality e5-s1 and it is not a service
part) farm.

Take care & stay well Max.
0 new messages