Buggy bookworm?

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.

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.

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.

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

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

And the clock is about 2 seconds out.

Yes, bookworm is surpisingly unstable.

If possible Id like to get systemd working properly

No, it does not

Its fine

Use the command timedatectl show-timesync --all to see where

LinkNTPServers= SystemNTPServers= RuntimeNTPServers= FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org

You can always specify NTP servers in

I basically uncommented everything that was commented out

Use timedatectl status to see what it is

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

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"

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?

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>).

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

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

I don't disagree with that!

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.

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

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.

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

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???

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.

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