Re: Buggy WNRO fixup
On 12-02-2022 08:37, Hal Murray wrote: Please try git head. I fixed my test case. Updated git again a few minutes ago. With these changes I see no WNRO messages thus far... If this was the intended behaviour: THANKS! Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 07:36, Gary E. Miller via devel wrote: A capture of the raw NMEA would be helpful. The other gps18x does not show the wrong date. So would a reset of the 'wrong date' gps18x work? Powerdown/up? Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 08:37, Hal Murray wrote: Please try git head. I fixed my test case. Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: ntpd ntpsec-1.2.1: Starting Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -x -N -p /var/run/ntpd.pid Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: precision = 0.908 usec (-20) Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: successfully locked into RAM Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: readconfig: parsing file: /etc/ntp.conf Feb 12 12:17:10 plnksrf ntpd[148642]: AUTH: authreadkeys: reading /etc/ntp/keys Feb 12 12:17:10 plnksrf ntpd[148642]: AUTH: authreadkeys: added 0 keys Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: restrict nopeer ignored Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: restrict nopeer ignored Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: 'monitor' cannot be disabled while 'limited' is enabled Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: Using SO_TIMESTAMPNS(ns) Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen and drop on 0 v6wildcard [::]:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 2 lo 127.0.0.1:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 3 eth0 192.168.10.70:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 4 lo [::1]:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listening on routing socket on fd #21 for interface updates Feb 12 12:17:10 plnksrf ntpd[148642]: SYNC: Found 15 servers, suggest minsane at least 3 Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: OpenSSL 1.1.1l FIPS 24 Aug 2021, 101010cf Feb 12 12:17:10 plnksrf ntpd[148642]: NTSc: Using system default root certificates. Feb 12 12:17:10 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:10 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:10 plnksrf ntpd[148641]: 2022-02-12T12:17:10 ntpd[148641]: INIT: ntpd ntpsec-1.2.1: Starting Feb 12 12:17:10 plnksrf ntpd[148641]: 2022-02-12T12:17:10 ntpd[148641]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -x -N -p /var/run/ntpd.pid Feb 12 12:17:11 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:11 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:12 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:12 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:13 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:13 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:14 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:14 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: DNS lookup of time.cloudflare.com:1234 took 0.023 sec Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: connecting to time.cloudflare.com:1234 => 162.159.200.123:1234 Feb 12 12:17:15 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate subject name: /C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=time.cloudflare.com Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate issuer name: /C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate is valid. Feb 12 12:17:15 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: read 750 bytes Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Using port 123 Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Got 7 cookies, length 100, aead=15. Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: NTS-KE req to time.cloudflare.com:1234 took 0.140 sec, OK Feb 12 12:17:16 plnksrf ntpd[148642]: NTSc: DNS lookup of ntpmon.dcs1.biz took 0.084 sec Feb 12 12:17:16 plnksrf ntpd[148642]: NTSc: connecting to ntpmon.dcs1.biz:4460 => 203.123.48.219:4460 Feb 12 12:17:16 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:16 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: connect_TCP_socket: connect failed: Connection refused Feb 12 12:17:17 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: DNS lookup of pi4.rellim.com took 0.241 sec Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: connecting to pi4.rellim.com:4460 => 204.17.205.24:4460 Feb 12 12:17:18 plnksrf
Re: Buggy WNRO fixup
On 12-02-2022 06:45, Hal Murray wrote: devel@ntpsec.org said: Is this an effect? I get loads of these: Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO That's a bug. Looks like it's alternating between 0 and 1024. Which sentence(s) are you using? What's your server line? (the mode part) I'm guessing you don't have one. Try adding "mode 1" Thanks for the report. ##NMEA zonder PPS refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 time2 0.260 baud 4800 # ## PPS van dezelfde NMEA GPS refclock pps unit 0 flag2 0 # vuurmuur server 192.168.10.98 minpoll 4 iburst Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 20-12-2021 21:51, Hal Murray via devel wrote: I have a NMEA unit that's off by 1024 weeks. Somebody is fixing it twice. Anybody know where that fixup code is located? I took a quick scan in the NMEA driver but didn't find it. Is this an effect? I get loads of these: Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:29 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 6 00:00:29 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:30 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 6 00:00:30 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:31 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: after network...
On 26-11-2021 06:52, Hal Murray wrote: ntpd does not start, reliably. What goes wrong? Is there an error message? What I can find in journalctl -b: systemd[1]: Dependency failed for Wait for ntpd to synchronize system clock. This is before the network scripts I still use (no network-manager...). network[2433]: WARN : [network] You are using 'network' service provided by 'network-scripts', which are now deprecated. network[2433]: WARN : [network] 'network-scripts' will be removed from distribution in near future. network[2433]: WARN : [network] It is advised to switch to 'NetworkManager' instead for network management. Thus I think it fails due to lack of network connectivity. Perhaps a simple tweak would be to have it wait longer but a real fix would be to start it after the network is up. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: after network...
On 22-11-2021 19:50, Richard Laager via devel wrote: What is the actual problem you are experiencing? ntpd does not start, reliably. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
after network...
Hello, Can we please adjust the service files so that also ntp-wait.service starts after we have network? Currently only ntpd.service has references to network... Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntp.ntpc wrong version
Hello, I built another ntpsec from git using the usual spec file, without errors as far as I could see. Yet, when I run the command below, I get some 'wrong version' output. What is wrong here and how do I correct? # /usr/bin/ntpq -c kerninfo associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart, pll offset:0 pll frequency: 0 maximum error: 2.04752 estimated error: 1.6e-05 kernel status: pll mode=fll pll time constant: 4 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0.0 calibration interval 4 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 ntp.ntpc wrong version b'1.2.0 2019-08-02T00:00:00Z' !== 1.2.0 2019-08-02T00:00:00Z# Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq broken on new Debian box
On 14-10-2020 20:04, James Browning via devel wrote: > Not your system it's mine. In the interim, move the libntpc files up a > level. I should have a patch soon. Simply check ld.so.conf and rerun ldconfig. Was easy fix on Fedora. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The_NTPsec_Project_is_pleased_to_announce_the_tagging_of_version_1.2.0
On 08-10-2020 12:55, Hal Murray wrote: > It will probably help if you provide your distro and what versions of python > appear if you ask for python, python2, and python3 We are on fedora 31, x86_64, etc. Fedora appears to being moved towards python3. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The_NTPsec_Project_is_pleased_to_announce_the_tagging_of_version_1.2.0
On 07-10-2020 12:17, Udo van den Heuvel via devel wrote: > On 06-10-2020 20:27, Hal Murray via devel wrote: >> >>> and you can download the release tarballs with sums and signatures from >>> ftp://ftp.ntpsec.org/pub/releases/ >> >> It's not there yet. > > Other stuff that might not be 'there' yet shows when building the binaries: > > () (cut) Adding ' --pyshebang=/usr/bin/python3' to the 'waf configure' line helps with this issue. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The_NTPsec_Project_is_pleased_to_announce_the_tagging_of_version_1.2.0
On 06-10-2020 20:27, Hal Murray via devel wrote: > >> and you can download the release tarballs with sums and signatures from >> ftp://ftp.ntpsec.org/pub/releases/ > > It's not there yet. Other stuff that might not be 'there' yet shows when building the binaries: () + pushd /root/rpmbuild/BUILDROOT/ntpsec-1.2.0-0.fc31.x86_64 ~/rpmbuild/BUILDROOT/ntpsec-1.2.0-0.fc31.x86_64 ~/rpmbuild/BUILD/ntpsec-1.2.0 + mkdir -p ./etc/ntp/crypto ./etc/sysconfig ./etc/dhcp/dhclient.d ./usr/libexec + mkdir -p ./etc/ntp.d + mkdir -p ./var/lib/sntp ./var/lib/ntp ./var/log/ntpstats ./usr/lib/systemd/system + mkdir -p ./usr/lib/systemd/system + mkdir -p ./usr/share/doc/ntpsec + mkdir -p ./usr/share/doc/ntpsec/icons + mkdir -p ./usr/share/doc/ntpsec/includes + mkdir -p ./usr/share/doc/ntpsec/pic + mkdir -p ./etc/ntp/crypto/ + mv ./usr/bin/ntpdig ./usr/sbin + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/default.conf ./etc/ntp.conf + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-gpsd-json ./etc/ntp.d/ + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-gpsd-shm ./etc/ntp.d/ + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-minimal-logging ./etc/ntp.d/ + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-no-remote-configuration ./etc/ntp.d/ + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-performance-logging ./etc/ntp.d/ + install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.2.0/etc/ntp.d/use-pool ./etc/ntp.d/ + popd ~/rpmbuild/BUILD/ntpsec-1.2.0 + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-ldconfig + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip /usr/bin/strip + /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-python-bytecompile /usr/bin/python 1 0 Bytecompiling .py files below /root/rpmbuild/BUILDROOT/ntpsec-1.2.0-0.fc31.x86_64/usr/lib64/python3.7 using /usr/bin/python3.7 + /usr/lib/rpm/brp-python-hardlink + /usr/lib/rpm/redhat/brp-mangle-shebangs *** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh *** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. error: Bad exit status from /var/tmp/rpm-tmp.ORactd (%install) I.e.: more python version fixes needed. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: time changed from 2020-07-03 to 2022-05-18
On 03-07-2020 15:00, Hal Murray wrote: >> How can I avoid this from happening again? > > That isn't enough info to figure out what happened. Somehow, ntpd thought > the > time was way off, and you had the -g switch on that allowed it to take big > jumps. If you turn off the -g switch, ntpd will exit instead. You will have > to start it again by hand. (Or maybe systemd will restart it, but that's > another problem.) Done removing -g. > I'm guessing you have a GPS unit. (Or something similar, but GPS is the most > common source of non-network time.) What sort of GPS unit? gpsd? ... Garmin gps18x on the serial port with USB power. With just $GPGGA and $GPRMC enabled, so where did it find that weird date? > Things should be setup such that servers from the network sanity check your > GPS clock. What's in your ntp.conf? driftfile /var/lib/ntp/drift nts key /etc/letsencrypt/keys/_key-certbot.pem nts cert /etc/letsencrypt/csr/_csr-certbot.pem restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 time2 0.260 baud 4800 refclock pps unit 0 flag2 0 disable monitor server 192.168.10.98 minpoll 4 iburst server fd00:c0a8:a00:1::1 server time.cloudflare.com:1234 nts # TLS1.3 only server ntpmon.dcs1.biz nts server pi4.rellim.com nts server ntp1.glypnod.com nts server ntp2.glypnod.com nts server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ logconfig =syncall -clockall Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: time changed from 2020-07-03 to 2022-05-18
On 03-07-2020 10:34, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time stepped by 59097600.478559 >> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time changed from 2020-07-03 to >> 2022-05-18 > > That's why you don't trust the GPS time until you know it has a good > lock and also why you shouldn't start ntpd with the option to accept > such large clock steps. So we remove `-g` option. Or replace by `-x`? But how could it get 'the wrong impression' in the first place? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
time changed from 2020-07-03 to 2022-05-18
Hello, Had to reboot the box. When it came up it got the wrong date. It looks like ntpd had a role here: (...) Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], not found in smartd database. Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], can't monitor Current_Pending_Sector count - no Attribute 197 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], can't monitor Offline_Uncorrectable count - no Attribute 198 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], is SMART capable. Adding to "monitor" list. Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd, type changed from 'scsi' to 'sat' Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], opened Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], Samsung SSD 860 QVO 2TB, S/N:S4CYNF0M520076M, WWN:5-002538-e40feda39, FW:RVQ11B6Q, 2.00 TB Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], not found in smartd database. Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], can't monitor Current_Pending_Sector count - no Attribute 197 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], can't monitor Offline_Uncorrectable count - no Attribute 198 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdd [SAT], is SMART capable. Adding to "monitor" list. Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme0, opened Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme0, KINGSTON SKC2000M8250G, S/N:50026B72824168C0, FW:S2780101 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme0, is SMART capable. Adding to "monitor" list. Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme1, opened Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme1, KINGSTON SKC2000M8250G, S/N:50026B73324169CC, FW:S2780102 Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/nvme1, is SMART capable. Adding to "monitor" list. Jul 3 10:06:47 boombox smartd[2004]: Monitoring 4 ATA/SATA, 0 SCSI/SAS and 2 NVMe devices May 18 10:06:48 boombox ntpd[2055]: CLOCK: time stepped by 59097600.478559 May 18 10:06:48 boombox ntpd[2055]: CLOCK: time changed from 2020-07-03 to 2022-05-18 May 18 10:06:48 boombox ntpd[2055]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes (cut) We're running a fairly recent git version of ntpsec: ntpsec-1.1.9-0.fc31.x86_64 on Fedora 31 on kernel.org 5.7.7. How can I avoid this from happening again? Please let me know. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq vs Python 3.8
On 26-05-2020 00:31, Hal Murray via devel wrote: > Fedora is updating from Python 3.7 to 3.8. > > That breaks ntpq (and friends) because the installed ntp libraries are over > in 3.7 but ntpq is looking in 3.8 > > Is there a good/clean fix for this? Should the code that chops the ".py? off > the name also fixup the first line of the script to replace "python" with > "python3.x"? > When awe are looking into the python corner, can we please fix these build errors? (...) Bytecompiling .py files below /root/rpmbuild/BUILDROOT/ntpsec-1.1.9-0.fc31.x86_64/usr/lib64/python3.7 using /usr/bin/python3.7 + /usr/lib/rpm/brp-python-hardlink + /usr/lib/rpm/redhat/brp-mangle-shebangs mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh Processing files: ntpsec-1.1.9-0.fc31.x86_64 error: Invalid version (double separator '-'): 1.1.9.2019-08-02T00-00-00Z: python3.7dist(ntp) == 1.1.9.2019-08-02T00-00-00Z error: Invalid version (double separator '-'): 1.1.9.2019-08-02T00-00-00Z: python3dist(ntp) == 1.1.9.2019-08-02T00-00-00Z (cut) These have been around for quite a while. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
EX-REP...
Hello, What can I do about these EX-REP messages? Apr 17 06:31:34 doos ntpd[240324]: EX-REP: Count=99 Print=42, Score=2.097, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 17 06:31:34 doos ntpd[240324]: EX-REP: e400 4e54534e 40cdeadb 42681b33 01040024 18e57fcb f24b47ae 21b47952 39542a49 b8f8e1fa 8e846667 b27ab197 01080d25 Apr 17 06:39:19 doos ntpd[240324]: EX-REP: Count=102 Print=43, Score=2.465, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 17 06:39:19 doos ntpd[240324]: EX-REP: e400 4e54534e 20c93d0c 5053cd5f 01040024 59b03b6e 2b0629c0 bf26b47d 7c311fd5 3ce9356e 5cf3a3ac 8c3f911c 54ccbd97 Apr 17 07:05:10 doos ntpd[240324]: EX-REP: Count=104 Print=44, Score=2.488, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 17 07:05:10 doos ntpd[240324]: EX-REP: e400 4e54534e e70e832d 972f3d7a 01040024 20c9be12 94b1dc63 144bfd24 78046626 e8b72daa a401cb5a 10716e6c 89e0f980 Apr 17 07:58:02 doos ntpd[240324]: EX-REP: Count=106 Print=45, Score=2.101, M4 V4 from [2606:4700:f1::123]:123, lng=84 Apr 17 07:58:02 doos ntpd[240324]: EX-REP: e400 4e54534e 6b74baed 16df4e19 01040024 dcf1a2d4 ff229f14 bb816621 751a420b 990ec649 26d31bb1 b066c35c f56012e5 Apr 17 08:05:42 doos ntpd[240324]: EX-REP: Count=109 Print=46, Score=2.471, M4 V4 from [2606:4700:f1::123]:123, lng=84 Apr 17 08:05:42 doos ntpd[240324]: EX-REP: e400 4e54534e 6d41eaee 2f313961 01040024 5d55ebca 81487059 33ae016a 1ae36c02 f854a9cd 628a163b 879ee829 e45b31a1 Apr 17 08:32:06 doos ntpd[240324]: EX-REP: Count=111 Print=47, Score=2.483, M4 V4 from [2606:4700:f1::123]:123, lng=84 Apr 17 08:32:06 doos ntpd[240324]: EX-REP: e400 4e54534e 65c7585f 80643677 01040024 ef111a39 71655918 75fdfaa5 f729f92f 124bbf84 8e9e971e bf8b73c1 7ae177bc Apr 17 09:24:32 doos ntpd[240324]: EX-REP: Count=113 Print=48, Score=2.104, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 17 09:24:32 doos ntpd[240324]: EX-REP: e400 4e54534e 0b4914a4 6e670be1 01040024 a2f78136 2f021329 f05d71aa acc9a128 88dc7b97 47a651a4 bfb6a85e edd2b789 Apr 17 09:32:13 doos ntpd[240324]: EX-REP: Count=116 Print=49, Score=2.474, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 17 09:32:13 doos ntpd[240324]: EX-REP: e400 4e54534e ad98c837 593e90eb 01040024 07ffd22f 81594a6c 5bdfd281 1bdc1664 025c32e7 c4843cc7 ff3db501 ffd6ab4 (cut) Please let me know! Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 21:15, Achim Gratz via devel wrote: >If so, you must use the clear edge of the PPS (flag2 1). Why is that? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 11:31, Hal Murray wrote: >> I could switch to a NMEA clock sans PPS and a dedicated PPS clock? > > That's what I would try. So I went to: ##NMEA zonder PPS refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 time2 0.260 baud 4800 # ## PPS van dezelfde NMEA GPS refclock pps unit 0 flag2 0 A NMEA clock without, a PPS clock with PPS. (If I did that correctly) I also switches the two Garmin GPS18X's between this box and the firewall. On this workstation I see: $ ntpq -pn remote refid st t when poll reach delay offset jitter == xNMEA(0).GPS.0 l 18 64 377 0. -331.787 23.4930 xPPS(0) .PPS.0 l7 64 377 0. -0.8792 0.1323 +192.168.10.98 .GPS.1 u 98 128 377 0.2679 -0.7279 0.1074 *fd00:c0a8:a00: .GPS.1 u 126 128 377 0.2856 -0.5707 0.2049 2606:4700:f1:: .STEP. 16 1- 5120 0. 0. 0.0010 -2405:fc00:0:1: .PPS.1 8 104 128 377 172.2620 1.3215 1.2845 -2001:470:e815: .PPS.1 8 115 128 377 174.3298 -8.0867 1.0422 (cut) So I start to think the serial port might have an issue? The firewall shows: # ntpq -pn remote refid st t when poll reach delay offset jitter === oNMEA(0) .GPS.0 l 40 64 377 0. 0.1373 0. fd00:c0a8:a00:1 165.216.214.155 2 u8 64 377 0.3301 0.9063 0.1030 192.168.10.70 165.216.214.155 2 u 55 64 377 0.2456 0.8751 0.0562 2606:4700:f1::1 .NTS. 16 4- 2560 0. 0. 0.0010 -2a01:3f7:2:202: 194.58.202.202 8 30 64 377 36.1680 2.4365 0.9056 #2a03:b0c0:1:d0: 37.15.221.1892 8 43 64 377 23.1451 2.6572 1.8014 +2001:888:0:7::2 193.67.79.2022 u 23 64 377 14.3002 3.6927 0.3338 (cut) (also with kernel discipline) This looks more normal? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 00:55, Hal Murray wrote: >> So no error messages about gps/NMEA. > >> NMEA(0) .GPS.0 l 15 64 377 >> 0. 0. 0.0019 > > What's the line for that in your ntp.conf? Any fudge lines? driftfile /var/lib/ntp/drift nts key /etc/letsencrypt/keys/_key-certbot.pem nts cert /etc/letsencrypt/csr/_csr-certbot.pem restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 0.260 baud 4800 disable monitor server 192.168.10.98 minpoll 4 iburst server fd00:c0a8:a00:1::1 server time.cloudflare.com:1234 nts # TLS1.3 only server ntpmon.dcs1.biz nts server pi4.rellim.com nts server ntp1.glypnod.com nts server ntp2.glypnod.com nts server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ logconfig =syncall -clockall We have some `time`in place. See the nmea refclock. Has been there for ages. > What does stty say for the baud rate? # stty < /dev/ttyS0 speed 4800 baud; line = 18; intr = ; quit = ; erase = ; kill = ; eof = ; start = ; stop = ; susp = ; rprnt = ; werase = ; lnext = ; discard = ; ignbrk -brkint -imaxbel -opost -onlcr -isig -iexten -echo -echoe -echok -echoctl -echoke > What sort of GPS device ? What baud rate is it using? Garmin GPS18X 4800 bps. > Try stopping ntpd and running cat /dev/whatever > That should show some NMEA sentences. It does, even with the ntpd running. > The 377 reach shows that something is working but the rest of the line shows > that it isn't. > > The NMEA driver is strange in that it tries to merge both the NMEA and PPS. > I > guess that's good if it works, but it makes debugging things like this > complicated. I could switch to a NMEA clock sans PPS and a dedicated PPS clock? > I run with 2 separate servers. Here is the chunk from my ntp.conf > > server 127.127.20.0 prefer path /dev/ttyAMA0 mode 0x010011 > fudge 127.127.20.0 flag1 0# disable PPS > fudge 127.127.20.0 time2 0.600# Fixup offset > server 127.127.22.0# PPS signal, needs prefer > fudge 127.127.22.0 flag2 0# Rising edge > > That turns into: > *NMEA(0) .GPS.0 l 31 64 377 0. 10.9381 > 27.6977 > oPPS(0) .PPS.0 l 30 64 377 0. 0.0570 > 0.0004 Like more or less what I understand from this part... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 17:35, Udo van den Heuvel via devel wrote: > On 12-04-2020 17:25, ASSI via devel wrote: >>> # ppswatch /chroot/ntpd/dev/pps0 >>> (shows similar output) >> >> Good, but does ntpd see the same? > > Well, devices look like this: And pps debug messages: # dmesg|grep event [ 408.583301] pps pps0: PPS event at 1586955482.000224958 [ 408.783290] pps pps0: PPS event at 1586955482.200221526 [ 409.583276] pps pps0: PPS event at 1586955483.000216947 [ 409.783279] pps pps0: PPS event at 1586955483.200224550 [ 410.583256] pps pps0: PPS event at 1586955484.000219902 [ 410.783257] pps pps0: PPS event at 1586955484.200224501 [ 411.583231] pps pps0: PPS event at 1586955485.000214265 [ 411.783227] pps pps0: PPS event at 1586955485.200217887 [ 412.583211] pps pps0: PPS event at 1586955486.000214565 [ 412.783209] pps pps0: PPS event at 1586955486.200217559 [ 413.583183] pps pps0: PPS event at 1586955487.000207532 [ 413.783188] pps pps0: PPS event at 1586955487.200214856 [ 414.583161] pps pps0: PPS event at 1586955488.000204200 [ 414.783164] pps pps0: PPS event at 1586955488.200212572 [ 415.583138] pps pps0: PPS event at 1586955489.000201916 [ 415.783140] pps pps0: PPS event at 1586955489.200209170 [ 416.583115] pps pps0: PPS event at 1586955490.000202426 [ 416.783117] pps pps0: PPS event at 1586955490.200206886 We can recognise the 200 ms pulse length of the gps. And some messages: # grep ntp /var/log/messages|grep -v NTSc Apr 15 14:57:52 doos ntpd[13057]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 15 14:57:52 doos ntpd[13057]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 15 14:57:52 doos ntpd[13058]: INIT: precision = 1.466 usec (-19) Apr 15 14:57:52 doos ntpd[13058]: INIT: successfully locked into RAM Apr 15 14:57:52 doos ntpd[13058]: CONFIG: readconfig: parsing file: /etc/ntp.conf Apr 15 14:57:52 doos ntpd[13058]: AUTH: authreadkeys: reading /etc/ntp/keys Apr 15 14:57:52 doos ntpd[13058]: AUTH: authreadkeys: added 0 keys Apr 15 14:57:52 doos ntpd[13058]: CONFIG: 'monitor' cannot be disabled while 'limited' is enabled Apr 15 14:57:52 doos ntpd[13058]: INIT: Using SO_TIMESTAMPNS Apr 15 14:57:52 doos ntpd[13058]: IO: Listen and drop on 0 v6wildcard [::]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 2 lo 127.0.0.1:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 3 eth0 192.168.10.70:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 4 lo [::1]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 5 eth0 [fd00:c0a8:a00:1::70]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 6 eth0 [2001:981:a812:0:b62e:99ff:fe92:5264]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 7 eth0 [fe80::b62e:99ff:fe92:5264%2]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listening on routing socket on fd #24 for interface updates Apr 15 14:57:52 doos ntpd[13058]: SYNC: Found 14 servers, suggest minsane at least 3 Apr 15 14:57:52 doos ntpd[13058]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Apr 15 14:57:52 doos ntpd[13058]: INIT: OpenSSL 1.1.1d FIPS 10 Sep 2019, 1010104f Apr 15 14:57:52 doos ntpd[13057]: 2020-04-15T14:57:52 ntpd[13057]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 15 14:57:52 doos ntpd[13057]: 2020-04-15T14:57:52 ntpd[13057]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 15 14:57:56 doos ntpd[13058]: EX-REP: Count=1 Print=1, Score=0.500, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 15 14:57:56 doos ntpd[13058]: EX-REP: e400 4e54534e 68b79e8c 7aba3928 01040024 ab1ba90e 83b3398e b52bc6be 4326e979 982bfea5 f885c05a 718c2243 47483da8 Apr 15 14:59:01 doos ntpd[13058]: EX-REP: Count=2 Print=2, Score=0.996, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 15 14:59:01 doos ntpd[13058]: EX-REP: e400 4e54534e fcbd5032 7356fdea 01040024 e445b468 d2d8f320 ea459fd8 86e68505 33cf4112 3f7d5a7d 9f2969df 4627b682 So no error messages about gps/NMEA. ntpq: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l 15 64 377 0. 0. 0.0019 192.168.10.98 .GPS.1 u 12 16 377 0.3325 0.8299 0.1966 fd00:c0a8:a00:1::1 .GPS.1 u4 64 377 0.3462 0.8608 0.7197 2606:4700:f1::1 .NTS. 16 0- 64 0 0. 0. 0.0019 2405:fc00:0:1::123 .PPS.1 8- 64 377 172.27
Re: crash
Hal, On 14-04-2020 05:07, Hal Murray wrote: > I just pushed a fix. Please test. With this fix the ntpd appears to be running a few hours now without issue. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 14-04-2020 07:22, Hal Murray wrote:
> Given that you have tested most of the rest of your ntp.conf, my guess would
> be file permissions on the certificate or key. The key is most likely since
> there is no reason to hide the certificate.
# cd /etc/letsencrypt/
# find . -exec ls -ld {} \;
drwxr-xr-x 7 root root 4096 Mar 5 09:37 .
drwxr-xr-x 2 root root 4096 Dec 13 11:05 ./csr
-rw-r--r-- 1 root root 932 Dec 13 11:05 ./csr/_csr-certbot.pem
drwxr-xr-x 2 root root 4096 Dec 13 11:05 ./renewal
drwxr-xr-x 3 root root 4096 Dec 13 11:05 ./accounts
drwxr-xr-x 3 root root 4096 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org
drwx-- 3 root root 4096 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org/directory
drwx-- 2 root root 4096 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org/directory/020c96242a59060882fc55ae933cc35e
-rw-r--r-- 1 root root 78 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org/directory/020c96242a59060882fc55ae933cc35e/regr.json
-r 1 root root 1632 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org/directory/020c96242a59060882fc55ae933cc35e/private_key.json
-rw-r--r-- 1 root root 77 Dec 13 11:05
./accounts/acme-v02.api.letsencrypt.org/directory/020c96242a59060882fc55ae933cc35e/meta.json
drwxr-xr-x 5 root root 4096 Dec 13 11:05 ./renewal-hooks
drwxr-xr-x 2 root root 4096 Dec 13 11:05 ./renewal-hooks/deploy
drwxr-xr-x 2 root root 4096 Dec 13 11:05 ./renewal-hooks/post
drwxr-xr-x 2 root root 4096 Dec 13 11:05 ./renewal-hooks/pre
drwx-- 2 root root 4096 Dec 13 11:05 ./keys
-rw--- 1 root root 1708 Dec 13 11:05 ./keys/_key-certbot.pem
Anything wrong in here?
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 14-04-2020 05:07, Hal Murray wrote: > >> # grep nts /etc/ntp.conf >> nts key /etc/letsencrypt/keys/_key-certbot.pem >> nts cert /etc/letsencrypt/csr/_csr-certbot.pem >> server time.cloudflare.com:1234 nts # TLS1.3 only > ... > > Thanks. > > I just pushed a fix. Please test. Will do, building rpm right now. > If you want the server side to support NTS, you need to add "nts enable" With that in ntp.conf the ntpd does not start. Config needed I guess. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 20:18, Hal Murray wrote: > It's dying while trying to reload the certificate file. > > Is that happening after running for an hour? Yes. > > That turns into 2 questions. Why is it trying to reload the certificates, > and > why is it crashing? > > What's in your ntp.conf? I don't need the whole thing, just the lines with > "nts". # grep nts /etc/ntp.conf nts key /etc/letsencrypt/keys/_key-certbot.pem nts cert /etc/letsencrypt/csr/_csr-certbot.pem server time.cloudflare.com:1234 nts # TLS1.3 only server ntpmon.dcs1.biz nts server pi4.rellim.com nts server ntp1.glypnod.com nts server ntp2.glypnod.com nts > Did this configuration work before a recent git pull? No. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 19:39, Hal Murray wrote: >> Or will I do the debug build? > > Please do it again with symbols. > > How long does it run before it crashes? Seconds? Hours? ... (gdb) bt #0 use_certificate_chain_file (ctx=ctx@entry=0x0, ssl=ssl@entry=0x0, file=file@entry=0x555f9640 "/etc/letsencrypt/csr/_csr-certbot.pem") at ssl/ssl_rsa.c:604 #1 0x77c5c36e in SSL_CTX_use_certificate_chain_file (ctx=ctx@entry=0x0, file=file@entry=0x555f9640 "/etc/letsencrypt/csr/_csr-certbot.pem") at ssl/ssl_rsa.c:688 #2 0x5558312e in nts_load_certificate (ctx=ctx@entry=0x0) at ../../ntpd/nts.c:225 #3 0x555832bc in nts_reload_certificate (ctx=0x0) at ../../ntpd/nts.c:204 #4 0x555840d5 in check_cert_file () at ../../ntpd/nts_server.c:171 #5 0x5558414d in nts_cert_timer () at ../../ntpd/nts_server.c:163 #6 0x55582d59 in nts_timer () at ../../ntpd/nts.c:107 #7 0x555739cd in timer () at ../../ntpd/ntp_timer.c:284 #8 0x55562051 in mainloop () at ../../ntpd/ntpd.c:940 #9 main (argc=, argv=) at ../../ntpd/ntpd.c:884 (gdb) An hour or so? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 16:01, Hal Murray wrote: > > udo...@xs4all.nl said: >> Started things this way. One gdb line worries me a bit: (No debugging symbols >> found in build/main/ntpd/ntpd) > >> Perhaps a different build is needed? > > I'm not sure how that stuff works. > > configure has an --enable-debug-gdb option. That may do it. With that option and some debuginfo's installed I get: Thread 1 "ntpd" received signal SIGSEGV, Segmentation fault. use_certificate_chain_file (ctx=ctx@entry=0x0, ssl=ssl@entry=0x0, file=file@entry=0x555f9640 "/etc/letsencrypt/csr/_csr-certbot.pem") at ssl/ssl_rsa.c:604 604 passwd_callback = ssl->default_passwd_callback; Missing separate debuginfos, use: dnf debuginfo-install libgpg-error-1.36-2.fc31.x86_64 (gdb) bt #0 use_certificate_chain_file (ctx=ctx@entry=0x0, ssl=ssl@entry=0x0, file=file@entry=0x555f9640 "/etc/letsencrypt/csr/_csr-certbot.pem") at ssl/ssl_rsa.c:604 #1 0x77c5c36e in SSL_CTX_use_certificate_chain_file (ctx=ctx@entry=0x0, file=file@entry=0x555f9640 "/etc/letsencrypt/csr/_csr-certbot.pem") at ssl/ssl_rsa.c:688 #2 0x5558312e in nts_load_certificate (ctx=ctx@entry=0x0) at ../../ntpd/nts.c:225 #3 0x555832bc in nts_reload_certificate (ctx=0x0) at ../../ntpd/nts.c:204 #4 0x555840d5 in check_cert_file () at ../../ntpd/nts_server.c:171 #5 0x5558414d in nts_cert_timer () at ../../ntpd/nts_server.c:163 #6 0x55582d59 in nts_timer () at ../../ntpd/nts.c:107 #7 0x555739cd in timer () at ../../ntpd/ntp_timer.c:284 #8 0x55562051 in mainloop () at ../../ntpd/ntpd.c:940 #9 main (argc=, argv=) at ../../ntpd/ntpd.c:884 (gdb) Hopefully this helps fixing the issue. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 16:01, Hal Murray wrote: > > udo...@xs4all.nl said: >> Started things this way. One gdb line worries me a bit: (No debugging symbols >> found in build/main/ntpd/ntpd) > >> Perhaps a different build is needed? > > I'm not sure how that stuff works. > > configure has an --enable-debug-gdb option. That may do it. Without that option I get: Thread 1 "ntpd" received signal SIGSEGV, Segmentation fault. 0x77c5ba70 in use_certificate_chain_file () from /lib64/libssl.so.1.1 Missing separate debuginfos, use: dnf debuginfo-install avahi-compat-libdns_sd-0.7-20.fc31.x86_64 avahi-libs-0.7-20.fc31.x86_64 dbus-libs-1.12.16-3.fc31.x86_64 libcap-2.26-6.fc31.x86_64 libgcc-9.3.1-1.fc31.x86_64 libgcrypt-1.8.5-1.fc31.x86_64 lz4-libs-1.9.1-1.fc31.x86_64 nss-mdns-0.14.1-7.fc31.x86_64 openssl-libs-1.1.1d-2.fc31.x86_64 systemd-libs-243.8-1.fc31.x86_64 xz-libs-5.2.4-6.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64 (gdb) bt #0 0x77c5ba70 in use_certificate_chain_file () from /lib64/libssl.so.1.1 #1 0x5558310e in ?? () #2 0x5558329c in ?? () #3 0x555840b5 in ?? () #4 0x5558412d in ?? () #5 0x55582d39 in ?? () #6 0x555739ad in ?? () #7 0x55562031 in ?? () #8 0x778f01a3 in __libc_start_main () from /lib64/libc.so.6 #9 0x5556232e in ?? () (gdb) Does this help enough? Or will I do the debug build? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 14:48, Hal Murray wrote: >> Apr 13 06:10:27 doos ntpd[204063]: EX-REP: Count=1 Print=1, Score=0.500, M4 >> V4 from [2606:4700:f1::1]:123, lng=84 > > That's saying the NTS stuff isn't working. 2606:4700:f1::1 is Cloudflare. > They have updated their servers to use the latest tweak from the draft RFC. > It's incompatible. I could disable NTSc for now to avoid crashes. Or if you have a patch I can test with that one? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 15:23, Hal Murray wrote: > when it crashes, you should get back to gdb > then > bt should give you a stack trace Started things this way. One gdb line worries me a bit: (No debugging symbols found in build/main/ntpd/ntpd) Perhaps a different build is needed? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 14:48, Hal Murray wrote:
> Can you get a stack trace?
I did not find a core dump.
How else can I get a stack dump?
> What were your configure options?
CFLAGS="-O2" %{__python3} ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
>> Apr 13 06:10:27 doos ntpd[204063]: EX-REP: Count=1 Print=1, Score=0.500, M4
>> V4 from [2606:4700:f1::1]:123, lng=84
>
> That's saying the NTS stuff isn't working. 2606:4700:f1::1 is Cloudflare.
> They have updated their servers to use the latest tweak from the draft RFC.
> It's incompatible.
Ah.
Would it help if I downgrade to a version a few weeks old?
-rw-r--r-- 1 root root 450224 Nov 22 07:32
RPMS/x86_64/ntpsec-1.1.8-0.fc31.x86_64.rpm
-rw-r--r-- 1 root root 450328 Dec 1 10:46
RPMS/x86_64/ntpsec-1.1.8-1.fc31.x86_64.rpm
-rw-r--r-- 1 root root 451781 Dec 13 10:53
RPMS/x86_64/ntpsec-1.1.8-2.fc31.x86_64.rpm
-rw-r--r-- 1 root root 451820 Dec 13 10:55
RPMS/x86_64/ntpsec-1.1.8-3.fc31.x86_64.rpm
-rw-r--r-- 1 root root 451848 Jan 4 17:49
RPMS/x86_64/ntpsec-1.1.8-4.fc31.x86_64.rpm
-rw-r--r-- 1 root root 452552 Feb 23 07:00
RPMS/x86_64/ntpsec-1.1.8-5.fc31.x86_64.rpm
-rw-r--r-- 1 root root 453601 Mar 14 14:39
RPMS/x86_64/ntpsec-1.1.8-6.fc31.x86_64.rpm
-rw-r--r-- 1 root root 453415 Apr 3 09:53
RPMS/x86_64/ntpsec-1.1.8-7.fc31.x86_64.rpm
-rw-r--r-- 1 root root 453667 Apr 12 09:30
RPMS/x86_64/ntpsec-1.1.8-8.fc31.x86_64.rpm
Or older?
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: crash
On 13-04-2020 14:13, Udo van den Heuvel via devel wrote: > All, > > This happens since yesterday: This is with a fairly recent 1.1.8 git build. Fedora is up to date. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
crash
All, This happens since yesterday: Apr 13 06:10:23 doos ntpd[204062]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 13 06:10:23 doos ntpd[204062]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 13 06:10:23 doos ntpd[204063]: INIT: precision = 1.397 usec (-19) Apr 13 06:10:23 doos ntpd[204063]: INIT: successfully locked into RAM Apr 13 06:10:23 doos ntpd[204063]: CONFIG: readconfig: parsing file: /etc/ntp.conf Apr 13 06:10:23 doos ntpd[204063]: AUTH: authreadkeys: reading /etc/ntp/keys Apr 13 06:10:23 doos ntpd[204063]: AUTH: authreadkeys: added 0 keys Apr 13 06:10:23 doos ntpd[204063]: CONFIG: 'monitor' cannot be disabled while 'limited' is enabled Apr 13 06:10:23 doos ntpd[204063]: INIT: Using SO_TIMESTAMPNS Apr 13 06:10:23 doos ntpd[204063]: IO: Listen and drop on 0 v6wildcard [::]:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 2 lo 127.0.0.1:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 3 eth0 192.168.10.70:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 4 lo [::1]:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 5 eth0 [fd00:c0a8:a00:1::70]:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 6 eth0 [2001:981:a812:0:b62e:99ff:fe92:5264]:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listen normally on 7 eth0 [fe80::b62e:99ff:fe92:5264%2]:123 Apr 13 06:10:23 doos ntpd[204063]: IO: Listening on routing socket on fd #24 for interface updates Apr 13 06:10:23 doos ntpd[204063]: SYNC: Found 14 servers, suggest minsane at least 3 Apr 13 06:10:23 doos ntpd[204063]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Apr 13 06:10:23 doos ntpd[204063]: INIT: OpenSSL 1.1.1d FIPS 10 Sep 2019, 1010104f Apr 13 06:10:23 doos ntpd[204062]: 2020-04-13T06:10:23 ntpd[204062]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 13 06:10:23 doos ntpd[204062]: 2020-04-13T06:10:23 ntpd[204062]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 13 06:10:27 doos ntpd[204063]: EX-REP: Count=1 Print=1, Score=0.500, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 13 06:10:27 doos ntpd[204063]: EX-REP: e400 4e54534e 6274db5e 604c0da9 01040024 31ecdfb4 899336cb a523b5e6 0f5d614a 766ff4ca 99384f4d a84fd23e 7e959900 Apr 13 06:11:34 doos ntpd[204063]: EX-REP: Count=2 Print=2, Score=0.995, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 13 06:11:34 doos ntpd[204063]: EX-REP: e400 4e54534e c0d6d0b1 7ff9fd3c 01040024 0ab1fdb5 06d34008 4477e202 f7c726b0 e8f662cc ef488b09 c4b3100b 8fc83793 Apr 13 06:12:38 doos ntpd[204063]: EX-REP: Count=3 Print=3, Score=1.487, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 13 06:12:38 doos ntpd[204063]: EX-REP: e400 4e54534e 79b3755d fcf61bc4 01040024 6502774b aafc5e82 fb0692fc 2ab219c9 05be1d8a 8db3d63d 61d2591d 08fe9f00 Apr 13 06:13:42 doos ntpd[204063]: CLOCK: time stepped by -0.227362 Apr 13 06:13:42 doos ntpd[204063]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Apr 13 06:14:07 doos ntpd[204063]: EX-REP: Count=4 Print=4, Score=1.968, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 13 06:14:07 doos ntpd[204063]: EX-REP: e400 4e54534e 735b5415 6c6af8af 01040024 e136691f 681af7eb 58590394 3fe8b189 4d7ec4cb 00658d17 a88bd4d7 542dd7da Apr 13 06:15:14 doos ntpd[204063]: EX-REP: Count=5 Print=5, Score=2.450, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 13 06:15:14 doos ntpd[204063]: EX-REP: e400 4e54534e 02999b2d 3e0fd596 01040024 3d2a4325 067694c7 4fce200e 841a6932 d94001f5 0fe4aa4f 09dd46d4 33149497 Apr 13 07:10:23 doos kernel: [52367.896238] ntpd[204063]: segfault at 17f8 ip 7f9d70252a70 sp 7ffe3665adc0 error 4 in libssl.so.1.1.1d[7f9d7022e000+5] Apr 13 07:10:23 doos kernel: ntpd[204063]: segfault at 17f8 ip 7f9d70252a70 sp 7ffe3665adc0 error 4 in libssl.so.1.1.1d[7f9d7022e000+5] openssl rpm is intact. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 17:25, ASSI via devel wrote: >> # ppswatch /chroot/ntpd/dev/pps0 >> (shows similar output) > > Good, but does ntpd see the same? Well, devices look like this: # ls -l /dev/*ps* lrwxrwxrwx 1 root root 5 Apr 12 16:54 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Apr 12 16:54 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 253, 0 Apr 12 16:54 /dev/pps0 # ls -l /dev/ttyS0 crw-rw 1 root ntp 4, 64 Apr 12 16:54 /dev/ttyS0 # ls -l /chroot/ntpd/dev/ total 0 lrwxrwxrwx 1 root root 5 Mar 9 2018 gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 gpspps0 -> pps0 srw-rw-rw- 1 root root 0 Apr 12 16:39 log crw-r--r-- 1 ntp ntp1, 3 Mar 9 2018 null crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 pps0 crw-r--r-- 1 ntp ntp4, 64 Mar 9 2018 ttyS0 So a process running as ntp could access the necessary device files. What else could be in the way of ntpd 'seeing' things? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 14:55, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> Using tsc clocksource we get: >> >> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource >> tsc >> # ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> === >> +NMEA(0) .GPS.0 l9 64 377 0. 0. >> 0.0019 >> *192.168.10.98 .GPS.1 u 27 64 377 0.3096 -0.0919 >> 0.1178 >> +fd00:c0a8:a00:1 .GPS.1 u 37 64 377 0.3211 -0.0505 >> 0.0775 >> >> I.e.: no system peer selection of GPS. >> We tried HPET, AC PI_PM and now TSC. >> None of them works to fix this issue. > > Then the clock isn't really the problem I suppose. The GPS is reachable > and has no offset and low jitter, but doesn't appear to use PPS; When then is the jitter so low? If solely using NMEA the jitter and offset would be worse. But: should ttyS0 show up in /proc/interrups? (ttyS1 does) Both are on a single pciE card. Setserial shows: # /bin/setserial /dev/ttyS0 /dev/ttyS0, UART: 16850, Port: 0xd0c0, IRQ: 37, Flags: low_latency # /bin/setserial /dev/ttyS1 /dev/ttyS1, UART: 16850, Port: 0xd0c8, IRQ: 37 # cat /dev/gps0 (NMEA stream) > although from your boot log it's clear you were apparently expecting to > use that. Have you set the flag to use the PPS and does the device > deliver (stable) PPS signal? # ppswatch /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" timestamp: 1586697390, sequence: 139, offset: 199075943 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698070, sequence: 148, offset: 196762613 # ppswatch /chroot/ntpd/dev/pps0 (shows similar output) Something is coming out of it. > If so, does the device file expected by > ntpd exist in your chroot environment (generally a symlink to the real > /dev/pps* device) and is it readable by ntpd? # ls -l /dev/*ps* lrwxrwxrwx 1 root root 5 Apr 12 11:58 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Apr 12 11:58 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 253, 0 Apr 12 11:58 /dev/pps0 # ls -l /chroot/ntpd/dev/*ps* lrwxrwxrwx 1 root root 5 Mar 9 2018 /chroot/ntpd/dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 /chroot/ntpd/dev/gpspps0 -> pps0 crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 /chroot/ntpd/dev/pps0 > Also, if there's an > apparmor profile for ntpd, check in /var/log/audit/audit.log (or > wherever that is under Fedora, also in the chroot maybe) that apparmor > allows the access as well. selinux is disabled. never used apparmor. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 11:43, Udo van den Heuvel via devel wrote: >> You might want to try if disabling C6 > > Thanks. Using tsc clocksource we get: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc # ntpq -pn remote refid st t when poll reach delay offset jitter === +NMEA(0) .GPS.0 l9 64 377 0. 0. 0.0019 *192.168.10.98 .GPS.1 u 27 64 377 0.3096 -0.0919 0.1178 +fd00:c0a8:a00:1 .GPS.1 u 37 64 377 0.3211 -0.0505 0.0775 162.159.200.123 .STEP. 16 1- 10240 0. 0. 0.0019 -2405:fc00:0:1:: .PPS.1 8 21 64 377 172.4212 2.2202 0.8405 (cut) I.e.: no system peer selection of GPS. We tried HPET, AC PI_PM and now TSC. None of them works to fix this issue. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 11:39, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> So we went to tsc by disabling hpet but that one also has an issue. >> Now we are on acpi_pm. > > That is going to suck rocks. So it's just about any clock in your > system going backwards at times except the ACPI-PM? No. I see no system peer selected in ` ntpq- pn` so I suspect this issue has not vanished. > >> See https://pastebin.com/5BbgWVFt for a dmesg. > > That log is with HPET disabled. Exactly. > You might want to try if disabling C6 Thanks. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 10:33, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> When booting with hpet=disable we see stuff like: > > Well, what clock sources get reported on boot when you don't force > anything and which one gets ultimately selected by the kernel? Are you > actually using a kernel new enough to know about Ryzen CPU, and does it > have the latest microcode for it (assuming that the BIOS isn't up on the > latest release of that already)? Please upload the full boot log to one > of the paste services instead of trying to guess what might look > interesting. We use kernel 5.6.3. We use Fedora 31 and update quite religiously. BIOS ais at latest release from Gigabyte. We know hpet has an issue. So we went to tsc by disabling hpet but that one also has an issue. Now we are on acpi_pm. See https://pastebin.com/5BbgWVFt for a dmesg. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:10, Achim Gratz via devel wrote: > based on the comments in the source. Again, if you don#t actually use > hardpps (and if this is the same Ryzen system you've had the timer > trouble on) it would be much more likely to work if you didn't configure > NTP_PPS and left the timer selection at the automoatic choice TSC > instead of forcing HPET. When booting with hpet=disable we see stuff like: [ 49.411072] usb 1-6.3: new full-speed USB device number 4 using xhci_hcd [ 60.413459] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: [ 60.413460] clocksource: 'acpi_pm' wd_now: 9efd1b wd_last: 4c447b mask: ff [ 60.413461] clocksource: 'tsc' cs_now: 46847f4e13 cs_last: 3d27b1ddd6 mask: [ 60.413461] tsc: Marking TSC unstable due to clocksource watchdog [ 60.413473] usb 3-6.1: New USB device strings: Mfr=1, Product=3, SerialNumber=3 [ 60.413484] sdc: sdc1 sdc2 sdc4 [ 60.413931] ata6.00: Enabling discard_zeroes_data [ 60.414026] sd 5:0:0:0: [sdc] Attached SCSI removable disk [ 61.103005] usb 3-6.1: Product: 00 [ 61.103006] usb 3-6.1: Manufacturer: Moonbase Otago http://www.moonbaseotago.com/random [ 61.103007] usb 3-6.1: SerialNumber: 00 [ 61.103031] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 61.389493] sched_clock: Marking unstable (61145974825, -42941333)<-(61315108884, -212077652) [ 61.389516] Freeing unused kernel image (initmem) memory: 1056K I.e.: messages about TSC appear to be not too positive. Gigabyte customer support were informed about this. when running without HPET ntpd still does not select NMEA gps as system peer. So HPET is not the cause now. But what is? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS-KE req fail
On 23-02-2020 11:30, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail > > You'd need the /^NTSc: / lines immediately preceding this to figure out > where it failed. There is no full separation of all the different fail > modes however, for instance a failed certificate or AEAD check would be > in the same bucket as a failed client send request or responce > processing. Ah, thanks, then I find: NTSc: certificate invalid: 10=>certificate has expired is that a local expiration or a remote one? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
NTS-KE req fail
Hello, What does a line of ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail signify? A remote issue? Or a local failure? What is failing exactly? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzz, Numbers
On 03-01-2020 06:06, Hal Murray wrote: > >>> Do you have a "disable monitor" in your ntp.conf? >> yes > > That turns off monitoring, aka the MRU list. I believe that was a security feature to prevent amplification of ddos-type attacks. (for ntp classic) Or doesn't this work this way for ntpsec? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzz, Numbers
On 02-01-2020 20:26, Hal Murray wrote: > That's not the normal output. > > Do you have a "disable monitor" in your ntp.conf? yes > What does "ntpq -c monstats" show? # ntpq -c monstats enabled:0 addresses: 0 peak addresses: 0 maximum addresses: 11915 reclaim above count:600 reclaim maxage: 3600 reclaim minage: 64 kilobytes: 0 maximum kilobytes: 1024 alloc: exists: 0 alloc: new: 0 alloc: recycle old: 0 alloc: recycle full:0 alloc: none:0 age of oldest slot: 0 # grep monitor /etc/ntp.conf disable monitor # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 13-12-2019 12:37, Hal Murray wrote: > Are you using a chroot jail? If so, does it let ntpd see the root certs? The chroot is the root cause I guess. Thanks for tipping me abotu taht one. I copied over /etc/pki to /chroot/ntpd/etc and stuff starts to see certs and such: Dec 13 12:42:57 sp2 ntpd[1589263]: NTSc: read 880 bytes Dec 13 12:42:57 sp2 ntpd[1589263]: NTSc: Got 8 cookies, length 104, aead=15. Dec 13 12:42:57 sp2 ntpd[1589263]: NTSc: NTS-KE req to ntp1.glypnod.com took 0.659 sec, OK Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: DNS lookup of ntp2.glypnod.com took 0.001 sec Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: nts_probe connecting to ntp2.glypnod.com:123 => [2a03:b0c0:1:d0::1f9:f001]:123 Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: certificate subject name: /CN=ntp2.glypnod.com Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: certificate issuer name: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: certificate is valid. Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: read 880 bytes Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: Got 8 cookies, length 104, aead=15. Dec 13 12:42:58 sp2 ntpd[1589263]: NTSc: NTS-KE req to ntp2.glypnod.com took 0.106 sec, OK Looks better to me... Thanks again for the tip! Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 13-12-2019 11:31, Udo van den Heuvel via devel wrote: > No change in ntpd behaviour... Certificates ended up in /etc/pki/tls/certs/ca-bundle.trust.crt and /etc/pki/tls/certs/ca-bundle.crt But after an ntpd restart no change... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 13-12-2019 11:21, Udo van den Heuvel via devel wrote: > On 13-12-2019 11:09, Udo van den Heuvel via devel wrote: >> So is this an isseu in the ca-certificates rpm? > > https://letsencrypt.org/certificates/ shows the relationships between > certificates. > Could it be that the Fedora rpm has no info on the X3 cert? Using the info at https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/ I palced some pem files (sans .txt) in /etc/pki/ca-trust/source/anchors/ and ran sudo update-ca-trust. Stuff looks like: # ls -tl total 12 -rw-r--r-- 1 root root 1647 Dec 13 11:27 lets-encrypt-x3-cross-signed.pem -rw-r--r-- 1 root root 2016 Dec 13 11:27 letsencryptauthorityx3.pem -rw-r--r-- 1 root root 1200 Dec 13 11:25 trustid-x3-root.pem No change in ntpd behaviour... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 13-12-2019 11:09, Udo van den Heuvel via devel wrote: > So is this an isseu in the ca-certificates rpm? https://letsencrypt.org/certificates/ shows the relationships between certificates. Could it be that the Fedora rpm has no info on the X3 cert? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
Hal, On 13-12-2019 10:56, Hal Murray wrote: > On Fedora, it's ca-certificates.noarch Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: DNS lookup of ntp2.glypnod.com took 0.031 sec Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: nts_probe connecting to ntp2.glypnod.com:123 => [2a03:b0c0:1:d0::1f9:f001]:123 Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: certificate subject name: /CN=ntp2.glypnod.com Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: certificate issuer name: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: certificate invalid: 20=>unable to get local issuer certificate Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: NTS-KE req to ntp2.glypnod.com took 0.086 sec, fail [root@sp2 ~]# rpm -q ca-certificates ca-certificates-2019.2.32-3.fc31.noarch So is this an isseu in the ca-certificates rpm? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 10-12-2019 06:47, Hal Murray wrote: > Do you have the normal collection of root certificates installed? Are they > up > to date? Can anybody confirm that installing the certificates for ntpd as a server can fix the client-side certificate issues as well? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
Hal, On 10-12-2019 06:47, Hal Murray wrote: >> I also might have a local issue as I get: >> NTSc: certificate invalid: 20=>unable to get local issuer certificate >> (for the other servers mentioned at the howto page) > > What OS/distro/version are you using? Fedora 31 Linux with kernel.org, git mesa, git amdgpu, git ntpsec, etc. > Do you have the normal collection of root certificates installed? Are they > up > to date? I do not hav the faintest idea. I guess I need to explain to ntpd that we have a certificate that can confirm the servers at the other side. I was away but will have some time for the next week. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 10-12-2019 06:18, Udo van den Heuvel via devel wrote: > Dec 10 05:52:57 s2 ntpd[984825]: NTSc: NTS-KE req to > time.cloudflare.com:1234 took 0.070 sec, fail I also might have a local issue as I get: NTSc: certificate invalid: 20=>unable to get local issuer certificate (for the other servers mentioned at the howto page) Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 10-12-2019 05:58, Hal Murray wrote: > openssl s_client -showcerts -quiet time.cloudflare.com:1234 # openssl s_client -showcerts -quiet time.cloudflare.com:1234 depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = time.cloudflare.com verify return:1 read:errno=0 Look similar to yours I guess. Yet, I get: Dec 10 05:52:57 s2 ntpd[984825]: NTSc: DNS lookup of time.cloudflare.com:1234 took 0.022 sec Dec 10 05:52:57 s2 ntpd[984825]: NTSc: nts_probe connecting to time.cloudflare.com:1234 => [2606:4700:f1::123]:123 Dec 10 05:52:57 s2 ntpd[984825]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) Dec 10 05:52:57 s2 ntpd[984825]: NTSc: certificate subject name: /C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=time.cloudflare.com Dec 10 05:52:57 s2 ntpd[984825]: NTSc: certificate issuer name: /C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA Dec 10 05:52:57 s2 ntpd[984825]: NTSc: certificate invalid: 19=>self signed certificate in certificate chain Dec 10 05:52:57 s2 ntpd[984825]: NTSc: NTS-KE req to time.cloudflare.com:1234 took 0.070 sec, fail Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 10-12-2019 05:03, Hal Murray wrote: > >> Also: NTSc: certificate invalid: 19=>self signed certificate in certificate >> chain > >> When I try nts as a client... > > Which host? > The first one in the howto: Public NTP servers supporting NTS: server time.cloudflare.com:1234 nts # TLS1.3 only Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: cloudflare refers NTS users to wrong page
On 09-12-2019 23:38, Paul Theodoropoulos via devel wrote: > https://docs.ntpsec.org/latest/NTS-QuickStart.html > > If anyone has a contact over at cloudflare, you might ask them to > correct this... Also: NTSc: certificate invalid: 19=>self signed certificate in certificate chain When I try nts as a client... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.8 build error
On 01-12-2019 23:51, Matthew Selsky wrote: > On Sun, Dec 01, 2019 at 10:45:28AM +0100, Udo van den Heuvel via devel wrote: >> Perhaps also in this way: >> >> rpmbuild -bb --define '_wrong_version_format_terminate_build 0' >> SPECS/ntpsec.spec > > Udo, > > Do you have a local patch that updates SPEC/ntpsec.spec for the version > information of each new release within the spec file? Nope, it is all manually done. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.8 build error
On 01-12-2019 10:14, Udo van den Heuvel via devel wrote: > The macro _wrong_version_format_terminate_build can be used to work > around this issue: Perhaps also in this way: rpmbuild -bb --define '_wrong_version_format_terminate_build 0' SPECS/ntpsec.spec Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.8 build error
Hello, The macro _wrong_version_format_terminate_build can be used to work around this issue: On 01-12-2019 09:00, Udo van den Heuvel via devel wrote: > Processing files: ntpsec-1.1.8-1.fc31.x86_64 > error: Invalid version (double separator '-'): > 1.1.8.2019-08-02T00-00-00Z: python3.7dist(ntp) == 1.1.8.2019-08-02T00-00-00Z > error: Invalid version (double separator '-'): > 1.1.8.2019-08-02T00-00-00Z: python3dist(ntp) == 1.1.8.2019-08-02T00-00-00Z Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
1.1.8 build error
Hello, Previously 1.1.8 built OK, now I get: (...) + popd ~/rpmbuild/BUILD/ntpsec-1.1.8 + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-ldconfig + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip /usr/bin/strip + /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-python-bytecompile /usr/bin/python 1 0 Bytecompiling .py files below /root/rpmbuild/BUILDROOT/ntpsec-1.1.8-1.fc31.x86_64/usr/lib64/python3.7 using /usr/bin/python3.7 + /usr/lib/rpm/brp-python-hardlink + /usr/lib/rpm/redhat/brp-mangle-shebangs mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh Processing files: ntpsec-1.1.8-1.fc31.x86_64 error: Invalid version (double separator '-'): 1.1.8.2019-08-02T00-00-00Z: python3.7dist(ntp) == 1.1.8.2019-08-02T00-00-00Z error: Invalid version (double separator '-'): 1.1.8.2019-08-02T00-00-00Z: python3dist(ntp) == 1.1.8.2019-08-02T00-00-00Z Provides: config(ntpsec) = 1.1.8-1.fc31 ntpsec = 1.1.8-1.fc31 ntpsec(x86-64) = 1.1.8-1.fc31 Requires(interp): /bin/sh /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires(post): /bin/sh systemd-units Requires(preun): /bin/sh systemd-units Requires(postun): /bin/sh systemd-units (...) I see a complaint about a version thing; I will try to edit that out myself. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 15:11, James Browning via devel wrote: > I do not suppose this would be anything like issue 499. Different code. (?) 'straight' clock, no kernel issues identified (yet). Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 15:01, Eric S. Raymond wrote: > Udo van den Heuvel : >> I have an M8N on order, would that be compatible enough to this driver? >> If so: I could help test etc. > > That can't hurt - they speak the same protocol - but the big deal with > the T variant os a stationary mode you don't have. Ah, OK. The M8N was cheap so perhaps a fake; I can try to identify this when it comes in. As it was cheap the loss would not be big. As it appears I need a (real) M8T: What M8T board, cabling etc would I need to buy to interface to RS232? Would e.g. https://www.gnss.store/12-gnss-gps-modules be reputable enough? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
On 24-11-2019 14:18, Eric S. Raymond wrote: > Udo van den Heuvel via devel : >> I cam across this ublox ntpsec refclock: >> https://gitlab.com/trv-n/ntpsec-ublox >> Would it be usable for incorporation in the ntpsec tree? (...) > > I have filed an issue on its tracker titled "Work should be merged to > upstream". In it I encourage the developer to introduce himself on this > list so we can discuss what would be required to integrate. Thanks! I have an M8N on order, would that be compatible enough to this driver? If so: I could help test etc. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ublox refclock
Hello, I cam across this ublox ntpsec refclock: https://gitlab.com/trv-n/ntpsec-ublox Would it be usable for incorporation in the ntpsec tree? (AFAIK this is a 'straight' refclock; no extra lines needed besides rx/tx and pps) Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: recommended libs
On 04-11-2019 16:10, Udo van den Heuvel via devel wrote: > Question: > > Can anybody mention which libraries in the chroot I should have for > ntpsec's ntpd? > Things are working now but perhaps functionality can improve with the > right software in lib64. FWIW: so far I see these being used: # fuser -v * USERPID ACCESS COMMAND /chroot/ntpd/lib64/libnss_dns.so.2: ntp 26263 m ntpd /chroot/ntpd/lib64/libnss_systemd.so.2: ntp 26263 m ntpd /chroot/ntpd/lib64/libresolv.so.2: ntp 26263 m ntpd # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 14:36, Achim Gratz via devel wrote: > configuration, like so: > > CONFIG_NO_HZ_COMMON=y > CONFIG_NO_HZ_IDLE=y > # CONFIG_NO_HZ_FULL is not set > CONFIG_NO_HZ=y I do not understand why NO_HZ is necessary or even usable without conflict witgh PPS such as CONFIG_NO_HZ_COMMON. > CONFIG_PPS=y > # CONFIG_PPS_DEBUG is not set > # PPS clients support > # CONFIG_PPS_CLIENT_KTIMER is not set > CONFIG_PPS_CLIENT_LDISC=m > CONFIG_PPS_CLIENT_PARPORT=m > CONFIG_PPS_CLIENT_GPIO=m > # PPS generators support Except for the GPIO client that is what is in use here. > Once you have that working correctly you can try to enable hardpps, How? >> Yet we still see: >> REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported > > So does the PPS device exist and does it generate events? # ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791559.972049895, sequence: 62 source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791562.972080079, sequence: 65 source 0 - assert 1572791563.772082569, sequence: 65 - clear 1572791562.972080079, sequence: 65 > If it's > coming in via a serial device, have you started an ldattach to enable > the PPS line discipline? Yes, that makes the /dev/pps0 device appear. We start ntpd after this step. If it is a link to the actual device (as usual > /dev/gpspps0 -> /dev/pps0), does it point to the correct device? Are > the permissions on the device correct? Sure, in the chroot (!) the devices (created with mknod) are owned by ntp: # ls -l /chroot/ntpd/dev/ total 0 lrwxrwxrwx 1 root root 5 Mar 9 2018 gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 gpspps0 -> pps0 srw-rw-rw- 1 root root 0 Nov 3 13:29 log crw-r--r-- 1 ntp ntp1, 3 Mar 9 2018 null crw-r--r-- 1 ntp ntp 252, 0 Mar 9 2018 pps0 crw-r--r-- 1 ntp ntp4, 64 Mar 9 2018 ttyS0 If I run ntpd outside of the chroot the error dopes not appear and PPS works. So we take another look at the chroot... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:22, Udo van den Heuvel via devel wrote: > Thanks for your thoughts. I will post the results... # gzip -dc /proc/config.gz |grep NO_HZ # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set Yet we still see: REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported # gzip -dc /proc/config.gz |grep PPS CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:10, Achim Gratz via devel wrote: >> We do have continuous timer ticks enabled. > > That doesn't matter AFAIK. The incompatibility is already introduced by > > CONFIG_NO_HZ_COMMON=y Ah This box has that setting. The other does not. > based on the comments in the source. Again, if you don#t actually use > hardpps (and if this is the same Ryzen system you've had the timer > trouble on) it would be much more likely to work if you didn't configure > NTP_PPS and left the timer selection at the automoatic choice TSC > instead of forcing HPET. We force hpet on the kernel commandline. >> We do run a 250HZ configuration. > > I'm pretty sure that hardpps was never thotoughly tested with HZ that Thanks for your thoughts. I will post the results... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:35, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> yet: >> >> # grep PPS .config >> CONFIG_PPS=y >> # CONFIG_PPS_DEBUG is not set >> CONFIG_NTP_PPS=y > > If you really wanted to enable hardpps, then you _must_ disable NOHZ in > the kernel config and let ntpd know (via flag3) that the kernel PLL is > active. Otherwise, disable that option. We do have continuous timer ticks enabled. We do run a 250HZ configuration. # grep HZ .config CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:15, Udo van den Heuvel via devel wrote: > > On 03-11-2019 12:06, Hal Murray wrote: >> >>> We do see pps and nmea but ntpd does not choose the local gps. Why? >> >> How do you "see" them? > > I use `ntpq -pn` to see what the status is. > > >>> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 >> >> I don't understand what's going on. The 377 says it is working, but the >> 0. and 0.0019 say that it isn't working. >> >> Do you have the baud rate correct? > > Yes. > `cat /dev/gps0` shows the NEMA stream. > >> What is in clockstats? > > We have clocklist: > > ntpq> clocklist > associd=0 status=0012 1 event, clk_bad_format, > name="NMEA", > timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", > poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, > fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" > > > Then the 'badformat' is worrying. > What is wrong and how can I fix this? > > Also: when the GPS gives bad data, then why doesn't it use a different > clock as peer? We furthermore find: Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: NMEA(0) flag1 1 but PPSAPI fails yet: # grep PPS .config CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:06, Hal Murray wrote: > >> We do see pps and nmea but ntpd does not choose the local gps. Why? > > How do you "see" them? I use `ntpq -pn` to see what the status is. >> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 > > I don't understand what's going on. The 377 says it is working, but the > 0. and 0.0019 say that it isn't working. > > Do you have the baud rate correct? Yes. `cat /dev/gps0` shows the NEMA stream. > What is in clockstats? We have clocklist: ntpq> clocklist associd=0 status=0012 1 event, clk_bad_format, name="NMEA", timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" Then the 'badformat' is worrying. What is wrong and how can I fix this? Also: when the GPS gives bad data, then why doesn't it use a different clock as peer? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-2019 10:31, Udo van den Heuvel via devel wrote: > On 02-08-19 07:33, Udo van den Heuvel via devel wrote: >> On one machine I see something weird: >> >> # ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> === >> NMEA(0) .GPS.0 l 38 64 377 0. 0. >> 0.0019 (...) Similarly on another box: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 fd00:c0a8:a00:1::70 67.96.200.2183 u 40 64 377 0.5053 -0.9482 0.1484 192.168.10.70 67.96.200.2183 u 55 64 377 0.3385 -0.9747 0.1622 2001:888:0:7::2 193.67.79.2022 u 55 64 377 14.5311 -3.6038 0.2071 2001:888:0:7::22193.67.79.2022 u 39 64 377 15.4898 -3.6090 0.2897 2001:888:0:8::42193.79.237.142 u 26 64 377 15.4917 -3.3595 0.3590 193.67.79.202 .GPS.1 u 35 64 377 18.2123 -3.4533 0.3782 193.79.237.14 .GPS.1 u 44 64 377 15.3530 -3.8482 0.0702 162.23.41.10.MRS.1 u 34 64 377 31.6796 -3.7795 0.1488 130.149.17.8.GPS.1 u 39 64 377 38.8027 -1.9196 0.3486 131.188.3.222 .MBGh. 1 u 19 64 377 27.3543 -2.3403 0.0917 131.188.3.223 .PZFs. 1 u 46 64 377 27.6289 -2.2454 0.2238 keetweej.vanheusden.com .DNS. 16 u- 1024 0 0. 0. 0.0019 185.31.230.94 .INIT. 16 u- 1024 0 0. 0. 0.0019 ntp.nmi.nl .DNS. 16 u- 1024 0 0. 0. 0.0019 134.221.205.12 .INIT. 16 u- 1024 0 0. 0. 0.0019 # ntptime ntp_gettime() returns code 0 (OK) time e1692e8d.fc7a5b10 2019-11-03T10:46:37.986Z, (.986242416), maximum error 2150516 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -30.043 ppm, interval 4 s, maximum error 2150516 us, estimated error 16 us, status 0x2001 (PLL,NANO), time constant 0, precision 1.000 us, tolerance 500 ppm, pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. We do see pps and nmea but ntpd does not choose the local gps. Why? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-19 07:33, Udo van den Heuvel via devel wrote: > On one machine I see something weird: > > # ntpq -pn > remote refid st t when poll reach delay offset > jitter > === > NMEA(0) .GPS.0 l 38 64 377 0. 0. > 0.0019 > 192.168.10.98 .GPS.1 u3 16 377 0.5049 0.4519 > 0.0468 > fd00:c0a8:a00:1 .GPS.1 u 11 64 377 0.3664 0.4386 > 0.1500 > 2001:888:0:7::2 193.67.79.2022 u 18 64 377 15.2859 4.6559 > 0.1818 > 2001:888:0:7::2 193.79.237.142 u 20 64 377 15.2148 4.1001 > 0.2219 > 193.67.79.202 .DNS. 16 u- 10240 0. 0. > 0.0019 > 193.79.237.14 .DNS. 16 u- 10240 0. 0. > 0.0019 > 185.31.230.94 .DNS. 16 u- 10240 0. 0. > 0.0019 > 134.221.205.12 .DNS. 16 u- 10240 0. 0. > 0.0019 After a while: $ ntpq -pn remote refid st t when poll reach delay offset jitter === xNMEA(0) .GPS.0 l 39 64 377 0. 0. 0.0019 *192.168.10.98 .GPS.1 u4 16 377 0.3188 0.4948 0.0348 +fd00:c0a8:a00:1 .GPS.1 u 34 64 377 0.3338 0.3530 0.1080 -2001:888:0:7::2 193.79.237.142 u 42 64 377 14.9423 4.1657 0.2031 +2001:888:0:7::2 193.79.237.142 u 23 64 377 14.9395 4.0204 0.2603 193.67.79.202 .DNS. 16 u- 10240 0. 0. 0.0019 193.79.237.14 .DNS. 16 u- 10240 0. 0. 0.0019 185.31.230.94 .DNS. 16 u- 10240 0. 0. 0.0019 134.221.205.12 .DNS. 16 u- 10240 0. 0. 0.0019 This is the machine with CLOCK messages like: Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: ts_prev 1564734050 s + 602281287 ns, ts_min 1564734050 s + 602280310 ns Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: ts 1564734050 s + 602281287 ns Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: sys_fuzz 2305 nsec, prior fuzz 0.02107 Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: this fuzz -0.01769 Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: prev get_systime 0xe0ee70e2.9a2f0787 is 0.00593 later than 0xe0ee70e2.9a2efd93 Which do not disaopear with 'logconfig -clockall'. udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-19 07:12, Matthew Selsky wrote: > You can likely remove python-devel and python-devel. Did so. > Are your RPM packages published anywhere? Not currently. On one machine I see something weird: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l 38 64 377 0. 0. 0.0019 192.168.10.98 .GPS.1 u3 16 377 0.5049 0.4519 0.0468 fd00:c0a8:a00:1 .GPS.1 u 11 64 377 0.3664 0.4386 0.1500 2001:888:0:7::2 193.67.79.2022 u 18 64 377 15.2859 4.6559 0.1818 2001:888:0:7::2 193.79.237.142 u 20 64 377 15.2148 4.1001 0.2219 193.67.79.202 .DNS. 16 u- 10240 0. 0. 0.0019 193.79.237.14 .DNS. 16 u- 10240 0. 0. 0.0019 185.31.230.94 .DNS. 16 u- 10240 0. 0. 0.0019 134.221.205.12 .DNS. 16 u- 10240 0. 0. 0.0019 No preferred clock. Any ideas? (this is the 1.1.6 code) Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 20:33, Matthew Selsky wrote:
> To:
> %{__python3} ./waf configure \
> %{__python3} ./waf build
> DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
>
> Let's see if that helps.
Builds successfully after adapting the directories in the %files section.
> Is there a git repo for your spec file work?
No, just vi, but feel free to use.
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
BuildRequires: /usr/bin/pathfix.py
BuildRequires: python3-devel python3-psutil
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in the ntp-doc package.
%package doc
Summary: NTP documentation
Group: Documentation
Requires: %{name} = %{version}-%{release}
BuildArch: noarch
%description doc
This package contains NTP documentation in HTML format.
%prep
%setup -q
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" .
%build
CFLAGS="-O2" %{__python3} ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
CFLAGS="-O2" %{__python3} ./waf build
%install
DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
pushd $RPM_BUILD_ROOT
mkdir -p .%{_sysconfdir}/{ntp/crypto,sysconfig,dhcp/dhclient.d}
.%{_libexecdir}
mkdir -p .%{_sysconfdir}/ntp.d
mkdir -p .%{_localstatedir}/{lib/{s,}ntp,log/ntpstats} .%{_unitdir}
mkdir -p .%{_unitdir}
mkdir -p .%{_docdir}/ntpsec
mkdir -p .%{_docdir}/ntpsec/icons
mkdir -p .%{_docdir}/ntpsec/includes
mkdir -p .%{_docdir}/ntpsec/pic
mkdir -p .%{_sysconfdir}/ntp/crypto/
mv .%{_bindir}/ntpdig .%{_sbindir}
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/default.conf
.%{_sysconfdir}/ntp.conf
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-json
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-shm
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-minimal-logging
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-no-remote-configuration
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-performance-logging
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-pool
.%{_sysconfdir}/ntp.d/
popd
%post
%systemd_post ntpd.service
%preun
%systemd_preun ntpd.service
%postun
%systemd_postun_with_restart ntpd.service
%files
%{_sbindir}/*
%{_bindir}/*
%{_libdir}/python3.7/site-packages/ntp/*
%{_libdir}/python3.7/site-packages/ntp*info
%dir %attr(-,ntp,ntp) %{_sysconfdir}/ntp.d
%config(noreplace) %attr(644,ntp,ntp) %{_sysconfdir}/ntp.d/*
%{_unitdir}/*
%{_mandir}/*
%config(noreplace) %verify(not md5 size mtime) %attr(644,ntp,ntp)
%{_sysconfdir}/ntp.conf
%dir %attr(750,root,ntp) %{_sysconfdir}/ntp/crypto
%dir %attr(-,ntp,ntp) %{_localstatedir}/lib/ntp
%dir %attr(-,ntp,ntp) %{_localstatedir}/log/ntpstats
%ghost %attr(644,ntp,ntp) %{_localstatedir}/lib/ntp/drift
%files doc
%{_docdir}/ntpsec/*
%changelog
* Fri Jun 15 2018 Udo van den Heuvel 1.1.1-0
- Bump to 1.1.1
* Thu Mar 15 2018 Udo van den Heuvel 1.1.0-0
- Bump to 1.1.0
* Wed Mar 07 2018 Udo van den Heuvel 1.0.1-2
- Fresh git pull
* Sat Mar 03 2018 Udo van den Heuvel 1.0.1-1
- Bump to 1.0.1, include configs, service files, etc
* Tue Nov 14 2017 Udo van den Heuvel 1.0.0-0
- Create 1.0.0 package.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 19:00, Matthew Selsky wrote:
> You may need to specifically use %{__python3} when you call "waf" in the 2
> places in the %build section.
When I do these things I get:
Waf: Leaving directory `/usr/src/redhat/BUILD/ntpsec-1.1.6/build/main'
Traceback (most recent call last):
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 122, in waf_entry_point
run_commands()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 183, in run_commands
ctx=run_command(cmd_name)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 174, in run_command
ctx.execute()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 377, in execute
return execute_method(self)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py",
line 88, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py",
line 129, in recurse
user_function(self)
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wscript", line 962, in
init_handler
obj.execute()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 377, in execute
return execute_method(self)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 104, in execute
self.execute_build()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 123, in execute_build
self.post_build()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 280, in post_build
m(self)
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wscript", line 917, in bin_test
from wafhelpers.bin_test import cmd_bin_test
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wafhelpers/bin_test.py", line
11, in
import ntp.util
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/build/main/tests/pylib/ntp/util.py",
line 16, in
import ntp.ntpc
ImportError: No module named ntpc
error: Bad exit status from /var/tmp/rpm-tmp.3EkTlR (%build)
RPM build errors:
Macro expanded in comment on line 119: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 126: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 127: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 128:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.3EkTlR (%build)
So maybe not use --python=%{__python3} for waf?
Without this the rpm builds OK.
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:39, Udo van den Heuvel via devel wrote:
> The 1.1.6 code does not.
The workaround now works when I use the pathfix.py line with this
addition: %{buildroot}%{_sbindir}/*
The whole SPEC then looks like the stuff below.
How can we explain the existing shebangs?
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
BuildRequires: /usr/bin/pathfix.py
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in the ntp-doc package.
%package doc
Summary: NTP documentation
Group: Documentation
Requires: %{name} = %{version}-%{release}
BuildArch: noarch
%description doc
This package contains NTP documentation in HTML format.
%prep
%setup -q
%build
CFLAGS="-O2" ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
CFLAGS="-O2" ./waf build
%install
DESTDIR=$RPM_BUILD_ROOT ./waf install
pushd $RPM_BUILD_ROOT
mkdir -p .%{_sysconfdir}/{ntp/crypto,sysconfig,dhcp/dhclient.d}
.%{_libexecdir}
mkdir -p .%{_sysconfdir}/ntp.d
mkdir -p .%{_localstatedir}/{lib/{s,}ntp,log/ntpstats} .%{_unitdir}
mkdir -p .%{_unitdir}
mkdir -p .%{_docdir}/ntpsec
mkdir -p .%{_docdir}/ntpsec/icons
mkdir -p .%{_docdir}/ntpsec/includes
mkdir -p .%{_docdir}/ntpsec/pic
mkdir -p .%{_sysconfdir}/ntp/crypto/
mv .%{_bindir}/ntpdig .%{_sbindir}
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/default.conf
.%{_sysconfdir}/ntp.conf
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-json
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-shm
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-minimal-logging
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-no-remote-configuration
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-performance-logging
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-pool
.%{_sysconfdir}/ntp.d/
pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
%{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
%{buildroot}%{_sbindir}/*
popd
%post
%systemd_post ntpd.service
%preun
%systemd_preun ntpd.service
%postun
%systemd_postun_with_restart ntpd.service
%files
%{_sbindir}/*
%{_bindir}/*
%{_libdir}/python2.7/site-packages/ntp/*
%{_libdir}/python2.7/site-packages/ntp*info
%dir %attr(-,ntp,ntp) %{_sysconfdir}/ntp.d
%config(noreplace) %attr(644,ntp,ntp) %{_sysconfdir}/ntp.d/*
%{_unitdir}/*
%{_mandir}/*
%config(noreplace) %verify(not md5 size mtime) %attr(644,ntp,ntp)
%{_sysconfdir}/ntp.conf
%dir %attr(750,root,ntp) %{_sysconfdir}/ntp/crypto
%dir %attr(-,ntp,ntp) %{_localstatedir}/lib/ntp
%dir %attr(-,ntp,ntp) %{_localstatedir}/log/ntpstats
%ghost %attr(644,ntp,ntp) %{_localstatedir}/lib/ntp/drift
%files doc
%{_docdir}/ntpsec/*
%changelog
* Fri Jun 15 2018 Udo van den Heuvel 1.1.1-0
- Bump to 1.1.1
* Thu Mar 15 2018 Udo van den Heuvel 1.1.0-0
- Bump to 1.1.0
* Wed Mar 07 2018 Udo van den Heuvel 1.0.1-2
- Fresh git pull
* Sat Mar 03 2018 Udo van den Heuvel 1.0.1-1
- Bump to 1.0.1, include configs, service files, etc
* Tue Nov 14 2017 Udo van den Heuvel 1.0.0-0
- Create 1.0.0 package.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:27, Matthew Selsky wrote:
> See
> https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf
> for the change that we made to our CI targets.
Sure.
1.1.3 that is on my system has the correct shebangs.
The 1.1.6 code does not.
(...)
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
*** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.3GaOm3 (%install)
RPM build errors:
Macro expanded in comment on line 117: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 124: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 125: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 126:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.3GaOm3 (%install)
[root@surfplank2 redhat]# cd
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
[root@surfplank2 ntpsec-1.1.6-0.fc30.x86_64]# head usr/bin/ntpmon
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: BSD-2-Clause
'''\
Any keystroke causes a poll and update. Keystroke commands:
'a': Change peer display to apeers mode, showing association IDs.
'd': Toggle detail mode (some peer will be reverse-video highlighted
when on).
'h': Display helpscreen.
#
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:27, Matthew Selsky wrote: > On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > >> The build shows otherwise, else there would not be an error. >> Or did I miss a step in the build process? > > See > https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf > for the change that we made to our CI targets. Sure, but why then is there a complaint from the Redhat Fedora tool(s)? > The debian package replaces the shebangs. You can see how at > https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ > > You likely want to use the RPM macro that does the equivalent. I'm not > familiar enough with RPM packaging to give more specific advice. We have a tool Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:15, Matthew Selsky wrote: >> Can someone please fix the /usr/sbin/ntpdig error? it makes the >> workround fail... > > Our code works on both Python2 and Python3. Given F30's recent changes, we > switched our CI targets to explicitly point at python3. The build shows otherwise, else there would not be an error. Or did I miss a step in the build process? > We're going to leave the shebangs alone in the source for maximum > compatibility with upstream PEP recommendations. See also > packaging/packaging.adoc in the repo. Because the shebangs are not explicit the build fails. At least that is what I understand from the errors. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 15:24, Udo van den Heuvel via devel wrote:
> The script will exit with nonzero exit code, rendering the build failed.
When trying to work around this in my spec file, I use:
pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
%{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
Result:
(...)
+ pathfix.py -pni '/usr/bin/python2 -s'
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpfrob
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpkeygen
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpleapfetch
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntplogtemp
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpmon
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpq
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsnmpd
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsweep
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptime
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptrace
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpviz
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpwait
recursedown('/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages')
recursedown('/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp')
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/__init__.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/agentx.py:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/agentx_packet.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/control.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/magic.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/packet.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/poly.py:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/statfiles.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/util.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpfrob: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpkeygen:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpleapfetch: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntplogtemp:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpmon: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpq: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsnmpd:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsweep:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptime: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptrace:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpviz: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpwait:
updating
+ popd
~/rpmbuild/BUILD/ntpsec-1.1.6
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 0
Bytecompiling .py files below
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7
using /usr/bin/python2.7
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.2SXyXF (%install)
RPM build errors:
Macro expanded in comment on line 117: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 124: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 125: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 126:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.2SXyXF (%install)
QUESTION:
Can someone please fix the /usr/sbin/ntpdig error? it makes the
workround fail...
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 15:09, Udo van den Heuvel via devel wrote:
> Hello,
>
> The compile on Fedora 30 fails at the very end:
>
> (...)
> + /usr/lib/rpm/brp-python-hardlink
> + /usr/lib/rpm/redhat/brp-mangle-shebangs
> *** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
> #!/usr/bin/env python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
> *** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
> #!/usr/bin/env python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> error: Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
>
>
> RPM build errors:
> Macro expanded in comment on line 107: %{_sysconfdir}/sysconfig/ntpd
>
> Macro expanded in comment on line 114: %{_sysconfdir}/ntp/crypto/pw
>
> Macro expanded in comment on line 115: %{_sysconfdir}/dhcp/dhclient.d
>
> Macro expanded in comment on line 116:
> %{_sysconfdir}/dhcp/dhclient.d/ntp.sh
>
> Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
Probably has to do with the info at
https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
The buildroot policy script in /usr/lib/rpm/redhat/brp-mangle-shebangs
currently changes all python shebangs to python2 with a message like:
*** WARNING: mangling shebang in /usr/bin/taskotron_result from
#!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR, fix
it manually!
We will change it to:
*** ERROR: ambiguous python shebang in /usr/bin/taskotron_result:
#!/usr/bin/python. Change it to python3 (or python2) explicitly.
The script will exit with nonzero exit code, rendering the build failed.
Of course I can (try to) work around this in my spec file but I guess
the project also has to choose python2 or pyhton3...
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
1.1.6 build fails on FC30
Hello,
The compile on Fedora 30 fails at the very end:
(...)
+ pushd /root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
~/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
~/rpmbuild/BUILD/ntpsec-1.1.6
+ mkdir -p ./etc/ntp/crypto ./etc/sysconfig ./etc/dhcp/dhclient.d
./usr/libexec
+ mkdir -p ./etc/ntp.d
+ mkdir -p ./var/lib/sntp ./var/lib/ntp ./var/log/ntpstats
./usr/lib/systemd/system
+ mkdir -p ./usr/lib/systemd/system
+ mkdir -p ./usr/share/doc/ntpsec
+ mkdir -p ./usr/share/doc/ntpsec/icons
+ mkdir -p ./usr/share/doc/ntpsec/includes
+ mkdir -p ./usr/share/doc/ntpsec/pic
+ mkdir -p ./etc/ntp/crypto/
+ mv ./usr/bin/ntpdig ./usr/sbin
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/default.conf ./etc/ntp.conf
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-gpsd-json ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-gpsd-shm ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-minimal-logging ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-no-remote-configuration
./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-performance-logging
./etc/ntp.d/
+ install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-pool
./etc/ntp.d/
+ popd
~/rpmbuild/BUILD/ntpsec-1.1.6
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 0
Bytecompiling .py files below
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7
using /usr/bin/python2.7
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
*** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
RPM build errors:
Macro expanded in comment on line 107: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 114: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 115: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 116:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
How can we fix this?
Below is the spec file used.
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in
Re: logging
On 14-04-19 14:01, Hal Murray wrote: > backwards runs forever. ^C when you get bored. No output after running `backwards` for over 30 minutes. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 14-04-19 14:01, Hal Murray wrote: > I just pushed some tweaks. Would you please try attic/clock and hpet: # ./a.out res avg min dups CLOCK 1 1666 419CLOCK_REALTIME 400 5 444-1 CLOCK_REALTIME_COARSE 1 1657 419CLOCK_MONOTONIC 1 1659 419CLOCK_MONOTONIC_RAW 1 1560 419CLOCK_BOOTTIME Histogram: CLOCK_REALTIME, 1 ns per bucket, 100 samples. ns hits 41915 48881 489 666 838 835 83976 907 1440 908 23469 977 8036 978 28887 132652 1327 8072 1396 31944 1397161152 1466 48599 1467101238 1815 12310 1816 92305 1885 90201 1886238744 1955 56259 1956 74512 2234 7 2235 163 2304 666 2305 2327 17944 samples were bigger than 2305. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 14-04-19 14:01, Hal Murray wrote: > > udo...@xs4all.nl said: >> ntpsec 1.1.3's ntpd from >> ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz >> gives me after startup: > >> Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns, >> ts_min 1555163630 s + 594155713 ns > ... > > Thanks. > > So now we know it wasn't a recent change to ntpsec. > > Were there more clusters like that, or only one? Multiple cam later. I can try a cold boot later this week to see if that helps. > I just pushed some tweaks. Would you please try attic/clock and > attic/backwards from a recent git. clock should print some stuff and exit. > backwards runs forever. ^C when you get bored. Thanks! I'll see what I can do here. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 18:28, Achim Gratz via devel wrote: >> !? >> What /was/ the problem in that case? > > The same that you still see: the system clock gets stopped and two > consecutive reads of the clock read the same (or maybe time even goes > backwards when looked at with higher resolution). Timetravel possibility? After switching to tsc the logging continues. Also the PLL goes up and offsets rise. (just like before) Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 14:02, Hal Murray wrote: > Plese give it a quick try to see if ntpsec is the problem. How about just > trying the 1.1.3 release? ntpsec 1.1.3's ntpd from ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz gives me after startup: Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns, ts_min 1555163630 s + 594155713 ns Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts 1555163630 s + 594156272 ns Apr 13 15:53:50 bla ntpd[12382]: CLOCK: sys_fuzz 2374 nsec, prior fuzz 0.02254 Apr 13 15:53:50 bla ntpd[12382]: CLOCK: this fuzz -0.01891 Apr 13 15:53:50 bla ntpd[12382]: CLOCK: prev get_systime 0xe05c686e.981a94b6 is 0.01211 later than 0xe05c686e.981a8064 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 15:29, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> Fedora 29, kernel.org 4.19.30. (my compile) > > Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the > kernel command line in the boot manager and see if that helps. # grep HZ .config|grep -v ^# CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y CONFIG_HZ_250=y CONFIG_HZ=250 tickless does not go with PPS support... >> AMD Ryzen 5 2400G with Radeon Vega Graphics > > While Raven Ridge should fully work with 4.19, there were mutiple fixes > for covering all sorts of things in later kernels. I'm not sure how > many of these got backported by the Fedora folks, My kernel is from kernel.org and compiled by me. > the latest BIOS installed. I need faster memory for later BIOS. Perhaps later this year. >> clocksource is fixed at hpet since the previous situations where clock >> sync was weird/gone/etc. > > That likely wasn't your real problem then, and switching to HPET just > has made it less easy to detect. !? What /was/ the problem in that case? With tsc there was no real sync to pps. With hpet we do have sync to pps. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 12:21, Hal Murray wrote: >> I never ever saw these before. > > Something changed. All we have to do is figure out what/when. > > Was the switch to using HPET recent? hpet must have been the default until it wasn't or at least tsc stopped being stable. > Did you do a recent git pull? Do you know how to drive git bisect? I know about bisect but it is quite a task. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 10:09, Hal Murray via devel wrote: > Here is a typical batch of the confusing CLOCK printout: > > Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s + > 712154322 ns, ts_min 1555072655 s + 712153764 ns > Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 712154322 ns > Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior > fuzz 0.01594 > Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: this fuzz -0.01722 > Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: prev get_systime > 0xe05b050f.b64fb1ce is 0.00942 later than 0xe05b050f.b64fa201 > > It looks like something is screwed up with your system clock. Hmm... ? :-/ >> Fedora 29 on x86_64 with Garmin gps18x on rs232. > > x86_64 covers a lot of ground. Anything interesting about that system? Fedora 29, kernel.org 4.19.30. (my compile) AMD Ryzen 5 2400G with Radeon Vega Graphics on Gigabyte X470 AORUS ULTRA GAMING motherboard. ntpsec from git. > Did > it work correctly a while ago? Does it work without any refclocks? Did you > update the kernel recently? ... I did not see these messages before. > What do we know about the system timekeeping? I'm looking for two things. > The first is from ntpd, probably in your syslog, before switching logging to > the typical log file. It should be something like this: > Apr 12 22:51:29 hgm ntpd[724]: INIT: precision = 0.157 usec (-23) Apr 12 14:15:23 bla ntpd[2109]: INIT: precision = 1.816 usec (-19) > The other comes from the Linux kernel at boot time. I don't know a simple > grep expression to get what I want. Grep for clocksource is a good start, > but > poke around to see if there is anything interesting nearby. Grep for MHz may > be interesting. clocksource is fixed at hpet since the previous situations where clock sync was weird/gone/etc. # dmesg|grep clocksource [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.30 ro root=/dev/myvg/rootlv noexec=on noexec32=on vga=0xF06 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us acpi_enforce_resources=lax fbcon=font:VGA8x16 radeon.pcie_gen2=1 cgroup_disable=memory threadirqs plymouth.enable=0 rd.plymouth=0 mce=dont_log_ce panic=0 rd.lvm.vg=myvg radeon.dpm=1 zswap.enabled=1 rd.auto=1 audit=0 systemd.log_level=warning net.ifnames=0 acpi=force amdgpu.gttsize=8192 clocksource=hpet initrd=/initramfs-4.19.30.img [0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.30 ro root=/dev/myvg/rootlv noexec=on noexec32=on vga=0xF06 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us acpi_enforce_resources=lax fbcon=font:VGA8x16 radeon.pcie_gen2=1 cgroup_disable=memory threadirqs plymouth.enable=0 rd.plymouth=0 mce=dont_log_ce panic=0 rd.lvm.vg=myvg radeon.dpm=1 zswap.enabled=1 rd.auto=1 audit=0 systemd.log_level=warning net.ifnames=0 acpi=force amdgpu.gttsize=8192 clocksource=hpet initrd=/initramfs-4.19.30.img [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 133484873504 ns [0.05] clocksource: tsc-early: mask: 0x max_cycles: 0x33e4791d180, max_idle_ns: 440795290210 ns [0.288707] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [1.160577] clocksource: Switched to clocksource hpet [1.174849] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 2085701024 ns [2.433537] tsc: Refined TSC clocksource calibration: 3603.134 MHz [2.433787] clocksource: tsc: mask: 0x max_cycles: 0x33efe3ec317, max_idle_ns: 440795248122 ns > You need to be careful with the arithmetic. The ns per tick variable gets > adjusted by the clock drift. I never ever saw these before. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: logging
On 13-04-19 01:27, Hal Murray wrote: > I haven't had time to look carefully at the CLOCK problems. What sort of > hardware is that running on? Fedora 29 on x86_64 with Garmin gps18x on rs232. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
logging
Hello, What to think about logging like this: Apr 11 19:12:25 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 550 from [2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe]:38764, lng=1408 Apr 11 19:14:34 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 560 from [2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe]:38764, lng=1424 Apr 11 19:16:44 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 570 from [2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe]:38764, lng=1440 Apr 11 19:18:28 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 020 from 68.75.8.147:38764, lng=80 Apr 11 19:20:34 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 030 from 68.75.8.147:38764, lng=96 [many of these] Should I worry? Change config? On another box: Apr 12 14:15:23 box.local ntpd[2093]: 2019-04-12T14:15:23 ntpd[2093]: INIT: ntpd ntpsec-1.1.3 2019-04-07T11:49:43Z: Starting Apr 12 14:15:23 box.local ntpd[2093]: 2019-04-12T14:15:23 ntpd[2093]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid -i /chroot/ntpd Apr 12 14:15:28 box.local ntpd[2109]: PROTO: fd01:c0a8:a10:1::1 unlink local addr ::1 -> Apr 12 14:15:33 box.local ntpd[2109]: IO: Listen normally on 4 eth0 192.168.110.60:123 Apr 12 14:15:33 box.local ntpd[2109]: IO: Listen normally on 5 eth0 [fd01:c0a8:a10:1::60]:123 Apr 12 14:15:33 box.local ntpd[2109]: IO: Listen normally on 6 eth0 [2001:981:a812:0:e2d5:5eef:fee3:6b35]:123 Apr 12 14:15:33 box.local ntpd[2109]: IO: Listen normally on 7 eth0 [fe80::e2d5:5eef:fee3:6b35%2]:123 Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: ts_prev 1555072336 s + 595028760 ns, ts_min 1555072336 s + 595027293 ns Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: ts 1555072336 s + 595028760 ns Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01663 Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: this fuzz -0.01626 Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b03d0.9853b2dc is 0.6 later than 0xe05b03d0.9853b2c2 Apr 12 14:34:42 box.local ntpd[2109]: CLOCK: ts_prev 1555072482 s + 752318448 ns, ts_min 1555072482 s + 752317400 ns Apr 12 14:34:42 box.local ntpd[2109]: CLOCK: ts 1555072482 s + 752318448 ns Apr 12 14:34:42 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01758 Apr 12 14:34:42 box.local ntpd[2109]: CLOCK: this fuzz -0.01783 Apr 12 14:34:42 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b0462.c097de8e is 0.00677 later than 0xe05b0462.c097d332 Apr 12 14:34:57 box.local ntpd[2109]: CLOCK: ts_prev 1555072497 s + 745400752 ns, ts_min 1555072497 s + 745399215 ns Apr 12 14:34:57 box.local ntpd[2109]: CLOCK: ts 1555072497 s + 745400752 ns Apr 12 14:34:57 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01745 Apr 12 14:34:57 box.local ntpd[2109]: CLOCK: this fuzz -0.01718 Apr 12 14:34:57 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b0471.bed27a70 is 0.00109 later than 0xe05b0471.bed2789a Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s + 712154322 ns, ts_min 1555072655 s + 712153764 ns Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 712154322 ns Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01594 Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: this fuzz -0.01722 Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b050f.b64fb1ce is 0.00942 later than 0xe05b050f.b64fa201 Apr 12 14:42:48 box.local ntpd[2109]: CLOCK: ts_prev 1555072968 s + 724550807 ns, ts_min 1555072968 s + 724549760 ns Apr 12 14:42:48 box.local ntpd[2109]: CLOCK: ts 1555072968 s + 724550807 ns Apr 12 14:42:48 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01230 Apr 12 14:42:48 box.local ntpd[2109]: CLOCK: this fuzz -0.01707 Apr 12 14:42:48 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b0648.b97c0dfd is 0.00073 later than 0xe05b0648.b97c0cc3 Apr 12 14:48:26 box.local ntpd[2109]: CLOCK: ts_prev 1555073306 s + 699738523 ns, ts_min 1555073306 s + 699737476 ns Apr 12 14:48:26 box.local ntpd[2109]: CLOCK: ts 1555073306 s + 699738523 ns Apr 12 14:48:26 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01798 Apr 12 14:48:26 box.local ntpd[2109]: CLOCK: this fuzz -0.01401 Apr 12 14:48:26 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b079a.b321fe7a is 0.00336 later than 0xe05b079a.b321f8d8 Apr 12 14:51:14 box.local ntpd[2109]: CLOCK: ts_prev 1555073474 s + 735160940 ns, ts_min 1555073474 s + 735160382 ns Apr 12 14:51:14 box.local ntpd[2109]: CLOCK: ts 1555073474 s + 735160940 ns Apr 12 14:51:14 box.local ntpd[2109]: CLOCK: sys_fuzz 1816 nsec, prior fuzz 0.01322 Apr 12 14:51:14 box.local ntpd[2109]: CLOCK: this fuzz -0.01126 Apr 12 14:51:14 box.local ntpd[2109]: CLOCK: prev get_systime 0xe05b0842.bc33703a is 0.00074 later than 0xe05b0842.bc336efe Apr 12 15:35:02 box.local ntpd[2109]: CLOCK: ts_prev 1555076102 s + 595269459 ns, ts_min 1555076102 s + 595268412 ns Apr 12 15:35:02 box.local ntpd[2109]: CLOCK: ts 1555076102 s + 595269459 ns Apr 12
waf issue?
Hello,
In my spec file (for Fedora) I configure and build nptsec with:
%build
CFLAGS="-O2" ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
CFLAGS="-O2" ./waf build
%install
DESTDIR=$RPM_BUILD_ROOT ./waf install
Using this method we end up with service files for systemd with strings
in them like @BINDIR@ and @SBINDIR@.
Isn't waf supposed to handle this?
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 15:13, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> But it was runnning on clocksource tsc. > > Again no direct experience, but TSC should be stable these days unless > something is very much wrong with the drivers. ALso, I've seen reports > that Ryzen TSC is unstable when certain overclocking options are > activated. I am not overclocking this CPU. > >> We manually switched to hpet and things started stabilising slowly. > > HPET should be OK, but if you can figure out why the TSC doesn't work > that would be better. Why would tsc be better? > Check what clocksources are available, there > might actually multiple TSC to chose from. # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 14:43, Achim Gratz via devel wrote: >> Same as it ever was: > > How are we supposed to know that if you don't say it? Because I was happy and documented stuff on linuxpps.org. Because no backups were made there the documentation went missing. >> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. > > So is this a USB serial or is it an LVC model and you use a "true" > RS232C port? Pover is from USB. The rest is over RS232. Yes, we use an LVC model. > How do you create the necessary PPS device? udev. If you use a > serial device, have you set it to low_latency? rc.local > I haven't seen one of > these in person, but I believe the serial port for Ryzen systems is part > of the SuperIO, not the chipset itself. We have an RS232 PCIe card. >> When I switch the GPSses (I have two) the GPS works fine in the other >> box. So something on this box is hosed and I ruled out wiring, I guess. >> I reset the GPS configuration, I changed PPS pulse length, etc. > > What's that second system you talk about that seems to work? The firewall. ASRock QC5000M-ITX/PH with same gps connected very similarly. Just not on an RS232 card but one of the serial ports of the ITX. > versions is responsible). I suspect you've been relying on some > defaults which have changed, but that's just a guess. Sounds reasonable given that the situation is currently normalising after switchign the clocksource to hpet. (from tsc) >> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 >> 0.260 baud 4800 > > If you left the default message configuration on, then 4800 baud is way > too slow. 4800 works very well when you set it up like this: $PGRMO,,2*75 $PGRMO,GPRMC,1*3D $PGRMO,GPGGA,1*20 $PGRMC,A,42.9,100,,A,3,1,2,9,30*61 Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:37, Udo van den Heuvel via devel wrote: >> As long as the time is that much off, yes it'll do that. > > Time is not that much off. > It also happens when I sync the clock manually and then start ntpd. > >> Does anything in the boot log complain about unstable clock sources and >> or switching between different ones? > > It switches only during bootup. > Nothing unstable (?) to be seen. But it was runnning on clocksource tsc. We manually switched to hpet and things started stabilising slowly. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:16, Achim Gratz via devel wrote: >> 186 is not sensible. >> When I set it to 0.000 it still goes way up. > > As long as the time is that much off, yes it'll do that. Time is not that much off. It also happens when I sync the clock manually and then start ntpd. > Does anything in the boot log complain about unstable clock sources and > or switching between different ones? It switches only during bootup. Nothing unstable (?) to be seen. > How is the GPS connected and how do you get the PPS in? Same as it ever was: Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. >> Or we get this absurd PLL frequency. (4.19.23). > > Same thing most likely. Same thing as what? >> Of course this might just be timing, depending on how soon after bootup, >> at what spot in the PPS cycle ntpd came online. > > No. It's a problem with how you set up your GPS. It's registers with a > too large offset. When I switch the GPSses (I have two) the GPS works fine in the other box. So something on this box is hosed and I ruled out wiring, I guess. I reset the GPS configuration, I changed PPS pulse length, etc. And I did not change anythign when this started, I simply rebooted into a different kernel. >> But I am not yet convinced of that. >> Restarting leads to same results. > > Yes, as long as you don't correct the setup What is not correct? > over and over. Care to show your ntp.conf next time? # grep -v ^# /etc/ntp.conf |grep -v ^$ driftfile /var/lib/ntp/drift restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 0.260 baud 4800 disable monitor server 192.168.10.98 minpoll 4 iburst server fd01:c1a8:a01:2::1 server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ Not so complex Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 12:34, Achim Gratz via devel wrote: >> This behaviour is not normal. > > Uh, that is reporting from an ntpd that has just started and hasn't One that starts counting again after being up for a little while. > collected many statistics. So the only way it can get a PLL frequency > of 186ppm will be if that value is stored in the drift file. Do you > have one (usually found somewhere in /var/lib/ntp/), does it contain a > sensible value? 186 is not sensible. When I set it to 0.000 it still goes way up. >> is it software? >> >> rebooted again to 4.19.23 which shows different behaviour than 4.19.30 >> and 32. > > What are these version numbers, Linux kernel? Of course. > If so, this doesn't seem > to be a rasPi, what is it? No, x86_64 with AMD Ryzen. > Also, just mumbling about "different > behaviour" without showing at least one difference isn#t really going to > get you much help. We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going backa nd forth between the gps and remote clocks. Or we get this absurd PLL frequency. (4.19.23). Of course this might just be timing, depending on how soon after bootup, at what spot in the PPS cycle ntpd came online. But I am not yet convinced of that. Restarting leads to same results. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 11:21, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >>> How close are you to "true" time when you start the ntpd? >> >> Within 100's of ms if not better. > > If you are really that far off when you start ntpd, When simply rebooting? # ntpq -c kerninfo -pn associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, pll offset:25.623 pll frequency: 186.259 maximum error: 0.10146 estimated error: 0.00972 kernel status: pll nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0 calibration interval 0 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 remote refid st t when poll reach delay offset jitter === xNMEA(0) .GPS.0 l- 64 1 0. 48.1256 0. x192.168.10.98 .GPS.1 u 35 64 3 0.2999 27.4933 4.5941 fd00:c0a8:a00:1::1 .GPS.1 u7 64 1 0.3935 55.0019 0. 2001:888:0:7::2 193.67.79.2022 u5 64 1 14.9598 60.2632 0. 2001:888:0:7::22193.67.79.2022 u 60 64 1 15.5002 23.9193 0. 193.67.79.202 .STEP. 16 u- 128 0 0. 0. 0.0002 193.79.237.14 .STEP. 16 u- 128 0 0. 0. 0.0002 185.31.230.94 .STEP. 16 u- 128 0 0. 0. 0.0002 134.221.205.12 .STEP. 16 u- 128 0 0. 0. 0.0002 This behaviour is not normal. is it software? rebooted again to 4.19.23 which shows different behaviour than 4.19.30 and 32. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 28-03-19 20:45, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> On 27-03-19 17:39, Udo van den Heuvel wrote: >>> Why would ntpsec after a reboot move the pll to values at the edge of >>> what I am graphing using mrtg? >>> Before the reboot the pll values were closer to 0. > > Are you manipulating the time while ntpd is already started up? No. Only ntpd might. > How > close are you to "true" time when you start the ntpd? Within 100's of ms if not better. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
