[SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

ExposeGlobalistsMadness · 2023-08-17 17:45:40

After upgrading from Devuan Chimaera to Daedalus using bash commands on a Raspberry Pi, using out-of-the-box sysvinit as init, the clock did not update during sessions, sometimes for very roughly an hour or more.

The Pi isn't generally plugged in between sessions, and the clock needs to do network updates.

(Also note that odysee.com videos and livestreams generally just buffer for me without starting to play in a librewolf browser, perhaps due to a lack of synchronization? They do seem to play in firefox-esr, so it might be due to a bug in librewolf. A temporary solution that worked yesterday but recurs during today's session:

sudo apt-get remove pipewire* libpipewire* 
sudo apt-get install pavucontrol pulseaudio

See https://dev1galaxy.org/viewtopic.php?pid=41755#p41755).

Notice:

$ sudo service ntp status
NTP server is not running ... failed!

Interesting observations from others:-

1) "There are some changes in Bookworm (and hence Daedelus) that don't affect my PC but might others e.g. the packages that set the system clock and reduced accessibility support."(https://dev1galaxy.org/viewtopic.php?pid=42957#p42957)

2) For Bookworm, "The ntp package, which used to be the default way to set the system clock from a Network Time Protocol (NTP) server, has been replaced by ntpsec.
Most users will not need to take any specific action to transition from ntp to ntpsec." (https://www.debian.org/releases/bookwor … stem-clock)

3) If setting clock via BIOS, and "If ntp and nptdate aren't installed, you have no chance to use this path. BTW: with Daedalus(Bookworm) the path to the ntp.conf has changed to /etc/ntpsec." (https://dev1galaxy.org/viewtopic.php?pid=43252#p43252)

Although a Pi uses a Broadcom chip instead of a BIOS anyway, please note that ntpdate is not installed:

$ apt list --installed | grep ntp
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

ntp/stable,stable,now 1:4.2.8p15+dfsg-2~1.2.2+dfsg1-1 all [installed]
ntpsec/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]
python3-ntp/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]

Also, strangely, the path for ntp.conf may have changed indeed to /etc/ntpsec, because a copy was found there, but a copy was somehow found at /etc also.

When trying to update clock, adapted from https://forums.raspberrypi.com/viewtopi … 0e#p487981 :

$ sudo ntpd -gq
2023-08-17T02:50:00 ntpd[10338]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T02:50:00 ntpd[10338]: INIT: Command line: ntpd -gq
2023-08-17T02:50:00 ntpd[10338]: INIT: precision = 0.241 usec (-22)
2023-08-17T02:50:00 ntpd[10338]: INIT: successfully locked into RAM
2023-08-17T02:50:00 ntpd[10338]: CONFIG: readconfig: parsing file: /etc/ntpsec/ntp.conf
2023-08-17T02:50:00 ntpd[10338]: CONFIG: restrict nopeer ignored
2023-08-17T02:50:00 ntpd[10338]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
2023-08-17T02:50:00 ntpd[10338]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2023-12-28T00:00Z last=2017-01-01T00:00Z ofs=37
2023-08-17T02:50:00 ntpd[10338]: IO: unable to bind to wildcard address :: - another process may be running: Address already in use; EXITING

So "ntpd[10338]: IO: unable to bind to wildcard address :: - another process may be running: Address already in use"!

Continuing...

$ sudo /etc/init.d/ntp start
Starting NTP server: ntpd2023-08-17T02:50:15 ntpd[10372]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T02:50:15 ntpd[10372]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
.

Having written this, a little later the clock somehow updated, roughly an hour after boot as on recent occasions, although neither of those last two steps were taken on previous occasions. So why no update at boot? When upgrading to Daedalus, does some code need to be amended to enable ntp to start?

alexkemp · 2023-08-17 18:29:14

ntpdate has been deprecated for quite some time. You will NOT find it in Devuan (nor Debian] to download. Try apt search nptdate if you do not believe me (it returns zilch).

The word on the Debian beach is found within less /usr/share/doc/ntpdate/NEWS.Debian.gz (dated to Jan 16 2023) which says:

ntpsec (1.2.1+dfsg1-6) unstable; urgency=low
ntpsec is replacing ntp in Debian.
If you were already using ntpsec, you can stop reading now. For
those coming from ntp, NTPsec is a drop-in replacement for common
configurations, but some things have been removed or changed in the
name of security and/or maintainability:
https://docs.ntpsec.org/latest/ntpsec.html

ExposeGlobalistsMadness · 2023-08-17 19:15:35

Thanks for your prompt reply, alexkemp, it is appreciated! So what are common Devuan users to do? Starting up ntp fails again (sudo service ntp start), even though the clock somehow updated automatically much later during this same session!

Currently:

$ sudo service ntp status
NTP server is not running ... failed!

$ sudo service ntp start 
Starting NTP server: ntpd2023-08-17T15:07:05 ntpd[879]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-17T15:07:05 ntpd[879]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
.

Anyone?

alexkemp · 2023-08-17 20:09:15

Whilst searching for the ntp startup script I came across this:

$ less /usr/sbin/ntpdate

#! /bin/sh
#
# ntpdate - emulate the crufty old ntpdate utility from NTP Classic
#
# Not documented, as this is strictly a backward-compatibility shim. It's
# based on the recipes at
# http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
# with corrections for modern ntpdig options.

update:
removed extraneous ']'.

Last edited by alexkemp (2023-08-22 06:48:20)

Marjorie · 2023-08-17 20:09:30

ExposeGlobalistsMadness wrote:

So what are common Devuan users to do? Starting up ntp fails again (sudo service ntp start), even though the clock somehow updated automatically much later during this same session!

I use chrony. It seems to work reliably.

https://chrony-project.org/comparison.html

NB. the comparisons shown on this page are with ntp not with ntpsec.

Last edited by Marjorie (2023-08-17 20:10:53)

alexkemp · 2023-08-17 20:18:49

The startup scripts (remember, this is initscripts, not systemd) are in /etc/init.d, etc:

/etc/init.d/ntp
/etc/rc2.d/S03ntp
/etc/rc2.d/S03ntpsec
/etc/rc3.d/S03ntp
/etc/rc3.d/S03ntpsec
/etc/rc4.d/S03ntp
/etc/rc4.d/S03ntpsec
/etc/rc5.d/S03ntp
/etc/rc5.d/S03ntpsec

This is the init.d script:

#!/bin/sh
### BEGIN INIT INFO
# Provides: ntp
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Start NTP daemon
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
. /lib/lsb/init-functions
DAEMON=/usr/sbin/ntpd
PIDFILE=/var/run/ntpd.pid
test -x $DAEMON || exit 0
if [ -r /etc/default/ntp ]; then
. /etc/default/ntp
fi
if [ -e /run/ntp.conf.dhcp ]; then
NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp"
fi
RUNASUSER=ntp
UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
if test "$(uname -s)" = "Linux"; then
NTPD_OPTS="$NTPD_OPTS -u $UGID"
fi
case $1 in
start)
log_daemon_msg "Starting NTP server" "ntpd"
if [ -z "$UGID" ]; then
log_failure_msg "user \"$RUNASUSER\" does not exist"
exit 1
fi
start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping NTP server" "ntpd"
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --retry=TERM/30/KILL/5 --exec $DAEMON
log_end_msg $?
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
status)
status_of_proc $DAEMON "NTP server"
;;
*)
echo "Usage: $0 {start|stop|restart|try-restart|force-reload|status}"
exit 2
;;
esac

Now you can trace the scripts through & find out where it is failing (although you should have more than one error message to tell you what is happening.

HTH

ExposeGlobalistsMadness · 2023-08-18 22:14:47

I am grateful to everyone for your replies, and I trust that they could help some people, but as I don't know how to install chrony nor how to trace scripts, and until hopefully the root of the problem is found and implemented on Daedalus for arm64, a workaround that worked for me was implemented from https://dev1galaxy.org/viewtopic.php?pid=42483#p42483 .

On my Devuan Daedalus system, the /etc/elogind/system-sleep folder didn't exist, so in order to preserve the solution above, in case it is important, I thought to create the mentioned folder:

sudo mkdir /etc/elogind/system-sleep
sudo touch /etc/elogind/system-sleep/ntp.sh
sudo rnano -w /etc/elogind/system-sleep/ntp.sh

...and used the script:

#!/bin/sh
# To update clock
# Credit to bigcat, from https://dev1galaxy.org/viewtopic.php?pid=42483#p42483
case $1 in
        pre)
                /etc/init.d/ntpsec stop
                /bin/sleep 1
                ;;
        post)
                /usr/sbin/ntpd -gq
                /etc/init.d/ntpsec start
                ;;
esac

Then thought that some chown and chmod instructions were appropriate:-

sudo chown root:root /etc/elogind/system-sleep/ntp.sh 
sudo chmod +x /etc/elogind/system-sleep/ntp.sh

In case it can help any Devuan arm64 developer, please note that on one lone recent occasion, the clock somehow updated quickly before adding the script above, and a log reported at the time:

$ sudo cat /var/log/boot
[...]
Thu Aug 17 21:24:03 2023: Starting NTP server: ntpd2023-08-17T21:24:03 ntpd[2121]: INIT: ntpd ntpsec-1.2.2: Starting
Thu Aug 17 21:24:03 2023: 2023-08-17T21:24:03 ntpd[2121]: INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
Thu Aug 17 21:24:03 2023: .
Thu Aug 17 21:24:03 2023: Starting NTP server: ntpd2023-08-17T21:24:03 ntpd[2129]: INIT: ntpd ntpsec-1.2.2: Starting
Thu Aug 17 21:24:03 2023: 2023-08-17T21:24:03 ntpd[2129]: INIT: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 102:107
[...]

Thanks again. Please flag up if anything seems wrong, anyone. Thank you!

Last edited by ExposeGlobalistsMadness (2023-08-18 22:18:48)

delgado · 2023-08-19 09:33:10

Or it was a bug:

I got the same installation and error respective ntp on my pc.
Beside the fail-message, ntpd was actually running (ps ax | grep ntpd).
The final fix in my case was: apt purge ntp. EDIT: To have ntp in any case, additionally: apt install ntpsec

Description:
There were two init.d-scripts existing, both return "fail" on "status".
/etc/init.d/ntp
/etc/init.d/ntpsec
After doing apt purge ntp, the file /etc/init.d/ntp was gone and /etc/init.d/ntpsec status now returns correctly "running".
Re-installing for testing purposes: apt install ntp did not harm anymore, it turned into a basically empty (meta-)package. I don't remember the exact content, but ntp was a "real" package with functionality.

Summary / assumption: package ntp was not upgraded corectly by the new metapackage. The (installed file-)content changed after de- and re-installing it.

ExposeGlobalistsMadness wrote:

After upgrading from Devuan Chimaera to Daedalus (...)
$ sudo service ntp status
NTP server is not running ... failed!
(...)
2) For Bookworm, "The ntp package, which used to be the default way to set the system clock from a Network Time Protocol (NTP) server, has been replaced by ntpsec. (...)
$ apt list --installed | grep ntp
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

ntp/stable,stable,now 1:4.2.8p15+dfsg-2~1.2.2+dfsg1-1 all [installed]
ntpsec/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]
python3-ntp/stable,now 1.2.2+dfsg1-1 arm64 [installed,automatic]

Last edited by delgado (2023-08-19 09:54:59)

ExposeGlobalistsMadness · 2023-08-19 18:59:58

Great points, delgado! When following your reasoning and purging ntp, there was a signal given by apt proposing to autoremove the remaining two ntp packages (ntpsec and python3-ntp), as the operating system might be programmed to think that they were just dependencies to ntp:

$ sudo apt purge ntp
[...]
The following packages were automatically installed and are no longer required:
  ntpsec python3-ntp
Use 'sudo apt autoremove' to remove them.
[...]

apt otherwise points out that ntpsec was already installed and up-to-date:

$ sudo apt install ntpsec
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ntpsec is already the newest version (1.2.2+dfsg1-1).
ntpsec set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Developers, note from that output that "ntpsec set to manually installed", in case it could be of interest! Could that be why apt thinks that there is no ntpsec and no python3-ntp to autoremove:

$ sudo apt autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

The workaround ntp.sh script was removed, and after reboot, it looks indeed that ntpsec needed to be reinstalled as proposed by delgado, since the clock still didn't update after about 15 minutes. So after updating the system (no update found):

$ sudo apt remove ntpsec
[...]
The following packages will be REMOVED:
  ntpsec python3-ntp
[...]

$ sudo apt install ntpsec
[...]
The following NEW packages will be installed:
  ntpsec python3-ntp
[...]
Stopping NTP server: ntpd.
Starting NTP server: ntpd2023-08-19T12:51:22 ntpd[7742]: INIT: ntpd ntpsec-1.2.2: Starting
2023-08-19T12:51:22 ntpd[7742]: INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N 
-u ntpsec:ntpsec
.
[...]

And so the clock got updated with ntpsec and without ntp. Therefore, with the above adjustments, ntp gets replaced by ntpsec, which tracks Devuan's plan.

They're probably teething pains from updating from Chimaera to Daedalus, as this recently became released as stable. I'm getting other error messages e.g. re alsa; modules ppdev and parport_pc; and seatd (which looks set to get an update, according to a post today - https://dev1galaxy.org/viewtopic.php?pid=43565#p43565), and I wonder whether that might be connected to why videos don't usually play on a librewolf browser, as reported above (it is not in Devuan's or Debian's arm64 repos). Thanks again.

ExposeGlobalistsMadness · 2023-08-21 22:19:31

Correction: The clock updated ok on the first reboot after doing the steps described but not on the following sessions, somehow. So I continued just as delgado iterated, by installing ntp anew (sudo apt install ntp) as a final step:

Summary / assumption: package ntp was not upgraded corectly by the new metapackage. The (installed file-)content changed after de- and re-installing it.

The clock then updated for all of the following sessions.

ExposeGlobalistsMadness · 2023-08-22 11:32:50

Another test: during this new session, the clock did not update until it was updated manually (sudo service ntpsec restart) though the ethernet cable was connected, but the router and internet connection were not up until minutes into the session. So why doesn't ntpsec or any other relevant service recheck for an internet connection periodically?

Having to use the ntp.sh script is not an appropriate solution though, so maybe the '[SOLVED]' label should be removed?

ExposeGlobalistsMadness · 2023-08-30 16:08:36

Perhaps the reason for the errors with the clock not updating nor the ntp packages being corrected/updated for a long time is simply that one of my /etc/apt/sources.list entries was noted yesterday to be wrong:

deb http://deb.devuan.org/devuan daedalus-security main

Instead of:

deb http://deb.devuan.org/merged daedalus-security main

I also added deb-src lines to that sources.list and non-free-firmware non-free contrib entries on the daedalus-update and daedalus-security lines in case those could help.

As a result, when updating, ntp, ntpsec and python3-ntp were among the 25 packages upgraded then. The clock updates ok now, even with the ntp.sh workaround removed.

ExposeGlobalistsMadness · 2023-09-14 19:43:55

Clock still fails to update until roughly an hour after bootup very occasionally, two weeks later.

'[SOLVED]' in title cannot seem to be able to be removed.

The officially official Devuan Forum!

#1 2023-08-17 17:45:40

[SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#2 2023-08-17 18:29:14

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#3 2023-08-17 19:15:35

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#4 2023-08-17 20:09:15

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#5 2023-08-17 20:09:30

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#6 2023-08-17 20:18:49

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#7 2023-08-18 22:14:47

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#8 2023-08-19 09:33:10

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#9 2023-08-19 18:59:58

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#10 2023-08-21 22:19:31

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#11 2023-08-22 11:32:50

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#12 2023-08-30 16:08:36

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

#13 2023-09-14 19:43:55

Re: [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running

Board footer