RPI 4B.
Rebooted. Clock wrong.
1hr later, clock still wrong?

WTF?

--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s
agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

On 09/04/2024 17:00, The Natural Philosopher wrote:
> RPI 4B.
> Rebooted. Clock wrong.
> 1hr later, clock still wrong?

Probably due to using systemd-timesyncd which I've never seen actuall
working. Install the ntp service and it will work.

It's one of the many parts of Bookworm I've had to junk and restore the
way I did things in Bullseye.

---druck

On 4/9/24 15:47, druck wrote:
> On 09/04/2024 17:00, The Natural Philosopher wrote:
>> RPI 4B.
>> Rebooted. Clock wrong.
>> 1hr later, clock still wrong?
>
> Probably due to using systemd-timesyncd which I've never seen actuall
> working. Install the ntp service and it will work.
>
> It's one of the many parts of Bookworm I've had to junk and restore the
> way I did things in Bullseye.
>
> ---druck
>

timesyncd works fine. Make sure that the route to the internet isn't
blocked. Use the command timedatectl show-timesync --all to see where
timesyncd is looking for time. You can always specify NTP servers in
/etc/systemd/timesyncd.conf. Use timedatectl status to see what it is
doing.

--

Knute Johnson

On 9.4.2024 19.00, The Natural Philosopher wrote:
> RPI 4B.
> Rebooted. Clock wrong.
> 1hr later, clock still wrong?
>
> WTF?

Raspberry has no RTC chip, so it will lose time when
powered off.

If there is a decent NTP server in the network the Pi
is connected to, it will synchronize to the server.

The undesirable characteristic of systemd-timesyncd
is that it is not willing to pass the time to the local
network.

Just install the ntpsec package and let it take care of
the time. There is a top -type utility ntpmon included.

--

-TV

druck <news@druck.org.uk> wrote:
> On 09/04/2024 17:00, The Natural Philosopher wrote:
> > RPI 4B.
> > Rebooted. Clock wrong.
> > 1hr later, clock still wrong?
>
> Probably due to using systemd-timesyncd which I've never seen actuall
> working. Install the ntp service and it will work.
>
> It's one of the many parts of Bookworm I've had to junk and restore the
> way I did things in Bullseye.
>
I have bookworm running on two systems, one is a 2Gb Pi 4B and the
other is an ancient Beaglebone Black. Both show the right time
without any intervention from me. I checked and the Pi 4B is running
systemd-timesyncd. ...., and the BBB is also running systemd-timesyncd.

--
Chris Green
·

On 09/04/2024 21:47, druck wrote:
> On 09/04/2024 17:00, The Natural Philosopher wrote:
>> RPI 4B.
>> Rebooted. Clock wrong.
>> 1hr later, clock still wrong?
>
> Probably due to using systemd-timesyncd which I've never seen actuall
> working. Install the ntp service and it will work.
>

Its very very weird.

It is systemd.timesyncd, and it sometimes says it cant connect, and very
very occasionally seems to connect.

Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration
changed, trying to establish connection.
Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration
changed, trying to establish connection.
Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for
reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration
changed, trying to establish connection.
Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
connectivity, watching for changes.
Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration
changed, trying to establish connection.
Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server
51.89.151.183:123 (0.debian.pool.ntp.org).

That is, it hasn't actually contacted a time server in 12 hours.

And the clock is about 2 seconds out.

> It's one of the many parts of Bookworm I've had to junk and restore the
> way I did things in Bullseye.
>
Yes, bookworm is surpisingly unstable.

If possible Id like to get systemd working properly

> ---druck
>

--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

On 09/04/2024 23:32, Knute Johnson wrote:
> On 4/9/24 15:47, druck wrote:
>> On 09/04/2024 17:00, The Natural Philosopher wrote:
>>> RPI 4B.
>>> Rebooted. Clock wrong.
>>> 1hr later, clock still wrong?
>>
>> Probably due to using systemd-timesyncd which I've never seen actuall
>> working. Install the ntp service and it will work.
>>
>> It's one of the many parts of Bookworm I've had to junk and restore
>> the way I did things in Bullseye.
>>
>> ---druck
>>
>
> timesyncd works fine.

No, it does not

> Make sure that the route to the internet isn't
> blocked.

Its fine

Use the command timedatectl show-timesync --all to see where
> timesyncd is looking for time.

LinkNTPServers=
SystemNTPServers=
RuntimeNTPServers=
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org
2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=51.89.151.183
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-25,
RootDelay=3.021ms, RootDispersion=106us, Reference=55C7D665,
OriginateTimestamp=Wed 2024-04-10 10:01:40 BST, ReceiveTimestamp=Wed
2024-04-10 10:01:40 BST, TransmitTimestamp=Wed 2024-04-10 10:01:40 BST,
DestinationTimestamp=Wed 2024-04-10 10:01:40 BST, Ignored=no,
PacketCount=36, Jitter=684us }
Frequency=-804732

You can always specify NTP servers in
> /etc/systemd/timesyncd.conf.

I basically uncommented everything that was commented out

Use timedatectl status to see what it is
> doing.
>
timedatectl status
Local time: Wed 2024-04-10 10:29:13 BST
Universal time: Wed 2024-04-10 09:29:13 UTC
RTC time: n/a
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

In order to get this far I had to edit that file and I disabled wlan0 on
the Pi 4.
At some point it started working but doesn't seem to be *regularly*
contacting anything last entry from

$systemctl status systemd-timesyncd.service

Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server
51.89.151.183:123 (0.debian.pool.ntp.org)

--
“I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.”

― Leo Tolstoy

On 10/04/2024 09:30, Chris Green wrote:
> druck <news@druck.org.uk> wrote:
>> On 09/04/2024 17:00, The Natural Philosopher wrote:
>>> RPI 4B.
>>> Rebooted. Clock wrong.
>>> 1hr later, clock still wrong?
>>
>> Probably due to using systemd-timesyncd which I've never seen actuall
>> working. Install the ntp service and it will work.
>>
>> It's one of the many parts of Bookworm I've had to junk and restore the
>> way I did things in Bullseye.
>>
> I have bookworm running on two systems, one is a 2Gb Pi 4B and the
> other is an ancient Beaglebone Black. Both show the right time
> without any intervention from me. I checked and the Pi 4B is running
> systemd-timesyncd. ...., and the BBB is also running systemd-timesyncd.
>
All I know is that I powered the pi4B off for around 15 hours, and when
I rebooted it, it had an incorrect clock for at least two hours after
reboot.

That is unacceptable for an 'out of the box' OS install.

systemd-timesyncd may be fine, but whatever it was supposed to do, it
wasn't doing it.

And none of this is well documented. As someone remarked about CMAKE,
"software that cannot be used because *no one knows how it works*, is
useless"

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 09/04/2024 21:47, druck wrote:
> > On 09/04/2024 17:00, The Natural Philosopher wrote:
> >> RPI 4B.
> >> Rebooted. Clock wrong.
> >> 1hr later, clock still wrong?
> >
> > Probably due to using systemd-timesyncd which I've never seen actuall
> > working. Install the ntp service and it will work.
> >
>
> Its very very weird.
>
> It is systemd.timesyncd, and it sometimes says it cant connect, and very
> very occasionally seems to connect.
>
> Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
> connectivity, watching for changes.
> Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
> Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
> Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
> Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
> connectivity, watching for changes.
> Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server
> 51.89.151.183:123 (0.debian.pool.ntp.org).
>
> That is, it hasn't actually contacted a time server in 12 hours.
>
> And the clock is about 2 seconds out.
>
I don't think your poblem is with systemd-timesyncd, it's with the
network. You appear to have an unstable connection which is why it
keeps saying "Network configuration changed, trying to establish
connection."

Also that IP address doesn't work for me either:-

chris@bbb$ host 2.debian.pool.ntp.org
2.debian.pool.ntp.org has address 162.159.200.123
2.debian.pool.ntp.org has address 80.87.128.222
2.debian.pool.ntp.org has address 178.62.68.79
2.debian.pool.ntp.org has address 134.0.16.1
2.debian.pool.ntp.org has IPv6 address 2a00:2381:19c6::200
2.debian.pool.ntp.org has IPv6 address 2603:c020:c00d:af00:195:242:99:71
2.debian.pool.ntp.org has IPv6 address 2a0f:85c0::50
2.debian.pool.ntp.org has IPv6 address 2a00:fd80:aaaa:ffff::eeee:ff1
chris@bbb$ host 193.150.34.2
2.34.150.193.in-addr.arpa domain name pointer time.rdg.uk.as44574.net.
chris@bbb$ ping 193.150.34.2
PING 193.150.34.2 (193.150.34.2) 56(84) bytes of data.
^C
--- 193.150.34.2 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8172ms

chris@bbb$

I don't know why your system is trying 162.159.200.123 and not the
alternatives, mine seem to find a working IP OK. Is your DNS good?

--
Chris Green
·

On 10/04/2024 at 10:27, The Natural Philosopher wrote:
> On 09/04/2024 21:47, druck wrote:
>> On 09/04/2024 17:00, The Natural Philosopher wrote:
>>> RPI 4B.
>>> Rebooted. Clock wrong.
>>> 1hr later, clock still wrong?
>>
>> Probably due to using systemd-timesyncd which I've never seen actuall
>> working. Install the ntp service and it will work.
>>
>
> Its very very weird.
>
> It is systemd.timesyncd, and it sometimes says it cant connect, and very
> very occasionally seems to connect.
>
> Apr 09 20:45:51 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:45:53 Coriolanus systemd-timesyncd[547]: No network
> connectivity, watching for changes.
> Apr 09 20:45:58 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:46:08 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 193.150.34.2:123 (2.debian.pool.ntp.org).
> Apr 09 20:46:18 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 77.104.162.218:123 (2.debian.pool.ntp.org).
> Apr 09 20:46:28 Coriolanus systemd-timesyncd[547]: Timed out waiting for
> reply from 95.215.175.2:123 (2.debian.pool.ntp.org).
> Apr 09 20:55:54 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 20:55:55 Coriolanus systemd-timesyncd[547]: No network
> connectivity, watching for changes.
> Apr 09 20:56:00 Coriolanus systemd-timesyncd[547]: Network configuration
> changed, trying to establish connection.
> Apr 09 21:30:38 Coriolanus systemd-timesyncd[547]: Contacted time server
> 51.89.151.183:123 (0.debian.pool.ntp.org).
>
> That is, it hasn't actually contacted a time server in 12 hours.
>
> And the clock is about 2 seconds out.
>
>
>
>> It's one of the many parts of Bookworm I've had to junk and restore
>> the way I did things in Bullseye.
>>
> Yes, bookworm is surpisingly unstable.
>
> If possible Id like to get systemd working properly
>
>
>
>> ---druck
>>
>

I'd tend to agree with Chris Green - it's a network problem. What's the
default route? Do you have >1 network on the box?

The clock will stay "correct" without time syncronisation for some time.
One thing I do with every new box is run 'fake-hwclock save' every
minute (root crontab) so a reboot gets the nearly correct time immediately.

I've got bookworm running on a Model B Plus Rev 1.2 with no problems
(yet <g>).

--
Chris Elvidge, England
TEACHER IS NOT A LEPER

The Natural Philosopher <tnp@invalid.invalid> writes:

> And none of this is well documented. As someone remarked about CMAKE,
> "software that cannot be used because *no one knows how it works*, is
> useless"

Who remarked that and why? I fairly like cmake but I can't say I've used
it a lot.

On 09/04/2024 23:32, Knute Johnson wrote:
> On 4/9/24 15:47, druck wrote:
>> On 09/04/2024 17:00, The Natural Philosopher wrote:
>>> RPI 4B.
>>> Rebooted. Clock wrong.
>>> 1hr later, clock still wrong?
>>
>> Probably due to using systemd-timesyncd which I've never seen actuall
>> working. Install the ntp service and it will work.
>>
>> It's one of the many parts of Bookworm I've had to junk and restore
>> the way I did things in Bullseye.
>
> timesyncd works fine.  Make sure that the route to the internet isn't
> blocked.  Use the command timedatectl show-timesync --all to see where
> timesyncd is looking for time.  You can always specify NTP servers in
> /etc/systemd/timesyncd.conf.  Use timedatectl status to see what it is
> doing.
Of course the route to the internet isn't blocked, ntp and everything
else works fine.
Even if systemd-timesyncd did work there is no good reason to hand over
even more control of the machine to the insidious expanding mess of
systemd. There are alternatives which do one thing and one thing well,
systemd should just stick to being an init system.
---druck

On 4/10/24 15:04, druck wrote:

> systemd should just stick to being an init system.
>
> ---druck

I don't disagree with that!

--

Knute Johnson

On 10/04/2024 10:27, The Natural Philosopher wrote:
> Yes, bookworm is surpisingly unstable.

The way Bookworm has been set up by default in Raspbian might be, I
certainly don't like it. If you upgrade in place from Bullseye, despite
the warnings, it is rock solid.

> If possible Id like to get systemd working properly

The only way systemd will work properly is when the last vestiges of
Linux have been replaced and you boot straight in to SystemD OS.

The best thing to do you don't want to use an alternative init system,
is just use systemd *just* as init system, and turn off all of it's
other tendrils.

---druck

Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> And none of this is well documented. As someone remarked about CMAKE,
>> "software that cannot be used because *no one knows how it works*, is
>> useless"
>
> Who remarked that and why? I fairly like cmake but I can't say I've used
> it a lot.

In my deliberately limited experience building software with CMake,
much of the trouble is that program developers are expected to
write detailed documentation for the build options they use, but
for the software I've compiled they simply haven't. You've got a
wall of options, and usually nothing short of reading source code
to decide what they do and which are important to you. Then it's
more awkward (than with a configure script) to reproduce those
settings if you want to compile a later version the same way.

--
__ __
#_ < |\| |< _#

On 10/04/2024 21:13, druck wrote:
> If you upgrade in place from Bullseye, despite the warnings, it is rock
> solid.

This is my experience on an x86-64 desktop, 2x VMs using x86-64 and 2x
RPi Zero W.

On 10/04/2024 11:14, Chris Green wrote:
> I don't know why your system is trying 162.159.200.123 and not the
> alternatives, mine seem to find a working IP OK. Is your DNS good?

No, it wasn't and I am not sure why.

I installed BIND which normally works out of the box.

Its the usual mess of network manager/systemd all fighting to control
something probably.

Yesterday I was getting connection refused on port 53, using the pi's
own IP address in resolv.conf - that is 192.168.0.101

I added a working server on the network, and it sprang to life but when
I tested it with its own address it now seems to work as well.

I just rebooted it and once again, DNS now works???

--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

On 09/04/2024 23:32, Knute Johnson wrote:
> timesyncd works fine.

Perhaps, but I prefer to run NTP everywhere, even on my Windows PCs.
One management UI, not several. I've seen other issues with bookworm, too.

--
Cheers,
David
Web: https://www.satsignal.eu

On 4/11/24 04:36, David Taylor wrote:
> On 09/04/2024 23:32, Knute Johnson wrote:
>> timesyncd works fine.
>
> Perhaps, but I prefer to run NTP everywhere, even on my Windows PCs.
> One management UI, not several.  I've seen other issues with bookworm, too.
>

You can do whatever you want.

--

Knute Johnson

On 4/11/24 04:10, The Natural Philosopher wrote:

> I installed BIND which normally works out of the box.

I'm curious why you did that and why you didn't mention it in your first
post?

--

Knute Johnson

On 11/04/2024 14:46, Knute Johnson wrote:
> On 4/11/24 04:10, The Natural Philosopher wrote:
>
>> I installed BIND which normally works out of the box.
>
> I'm curious why you did that and why you didn't mention it in your first
> post?
>
I had no idea thåt there was a DNS issue. I haven't modified BINDS
configuration, but now its *working*.

???

--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

On 4/11/24 11:21, The Natural Philosopher wrote:
> On 11/04/2024 14:46, Knute Johnson wrote:
>> On 4/11/24 04:10, The Natural Philosopher wrote:
>>
>>> I installed BIND which normally works out of the box.
>>
>> I'm curious why you did that and why you didn't mention it in your
>> first post?
>>
> I had no idea thåt there was a DNS issue. I haven't modified BINDS
> configuration, but now its *working*.
>
> ???
>

So I'm still curious, why did you install bind?

--

Knute Johnson

On 11/04/2024 21:49, Knute Johnson wrote:
> On 4/11/24 11:21, The Natural Philosopher wrote:
>> On 11/04/2024 14:46, Knute Johnson wrote:
>>> On 4/11/24 04:10, The Natural Philosopher wrote:
>>>
>>>> I installed BIND which normally works out of the box.
>>>
>>> I'm curious why you did that and why you didn't mention it in your
>>> first post?
>>>
>> I had no idea thåt there was a DNS issue. I haven't modified BINDS
>> configuration, but now its *working*.
>>
>> ???
>>
>
> So I'm still curious, why did you install bind?
>
I wanted a proper caching DNS server on my home network. One that I
could use to put local machines on. This PI is to be the house server.
Storage. Media. DNS. TV.

I've always used bind to do that. Usually it just works.

--
“There are two ways to be fooled. One is to believe what isn’t true; the
other is to refuse to believe what is true.”

—Soren Kierkegaard

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 11/04/2024 21:49, Knute Johnson wrote:
> > On 4/11/24 11:21, The Natural Philosopher wrote:
> >> On 11/04/2024 14:46, Knute Johnson wrote:
> >>> On 4/11/24 04:10, The Natural Philosopher wrote:
> >>>
> >>>> I installed BIND which normally works out of the box.
> >>>
> >>> I'm curious why you did that and why you didn't mention it in your
> >>> first post?
> >>>
> >> I had no idea thåt there was a DNS issue. I haven't modified BINDS
> >> configuration, but now its *working*.
> >>
> >> ???
> >>
> >
> > So I'm still curious, why did you install bind?
> >
> I wanted a proper caching DNS server on my home network. One that I
> could use to put local machines on. This PI is to be the house server.
> Storage. Media. DNS. TV.
>
> I've always used bind to do that. Usually it just works.
>
Yes, I do similar, but with dnsmasq. It used to be on my
desktop/server (permanently on because it's my mail server too) but I
have now moved it to a recently acquired Asus DSL router that runs
asuswrt-merlin software.

--
Chris Green
·