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 Sun, Dec 01, 2019 at 10:45:28AM +0100, Udo van den Heuvel via devel wrote: > 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 Udo, Do you have a local patch that updates SPEC/ntpsec.spec for the version information of each new release within the spec file? Thanks, -Matt ___ 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
Re: Fuzzing Messages
On 12/1/19 2:44 AM, Achim Gratz via devel wrote: > Richard Laager via devel writes: >> The issue persists when removing "nts" from "server" lines (i.e. >> disabling NTS client behavior). >> >> The problem goes away when disabling NTS server behavior. To clarify: If I run as an NTS client but not NTS server, then I get the "blocked for" errors on startup, but not past that (in short tests). > I don't serve NTS from the two test machines, so that would be an > additional code path to consider. So the NTS serving is probably why I get them on an ongoing basis and you don't. We both get them on startup from the DNS code. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
Richard Laager via devel writes: > The issue persists when removing "nts" from "server" lines (i.e. > disabling NTS client behavior). > > The problem goes away when disabling NTS server behavior. I don't serve NTS from the two test machines, so that would be an additional code path to consider. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
Richard Laager via devel writes: > That was the case for me _at startup_, but not after that. (See the > attached logs.) I think the culprit is somewhere in the NTS client code. >>> This would also explain why a server >>> that has many clients would see many more such errors. > > Why's that? What DNS lookups is ntpd doing for clients? I've seen the errors either in conjunction with pool refreshes or NTS handshakes. > Attached is what I have right away, filtered for DNS|CLOCK. Maybe add NTSc, see above. I haven't seen a fuzz error since installing the patched version, but as I said I would need another week or so to reasonably be able to correlate it to this change. I do get more messages about blockage than I used to get about fuzz errors, but maybe two or three times more, not an order of magnitude. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
On 12/1/19 2:17 AM, Richard Laager via devel wrote: > On 11/30/19 6:17 AM, ASSI via devel wrote: >> ASSI via devel writes: >>> is… intriguing. If you follow the code through the function, ts_min in >>> the log should always be ts_prev+sys_fuzz; these two values can't be >>> identical or differ by any other value, ts_min must strictly be greater >>> than ts_prev by sys_fuzz. I notice that there is always a DNS operation >>> logged at the same time when I get these errors, so I am pretty sure >>> this is related to the DNS thread. > > That was the case for me _at startup_, but not after that. (See the > attached logs.) > >>> This would also explain why a server >>> that has many clients would see many more such errors. > > Why's that? What DNS lookups is ntpd doing for clients? > >> While I have not yet identified the code path that is involved (likely >> something in NTS, I think), you might want to try the following monkey >> patch: The issue persists when removing "nts" from "server" lines (i.e. disabling NTS client behavior). The problem goes away when disabling NTS server behavior. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
On 11/30/19 6:17 AM, ASSI via devel wrote: > ASSI via devel writes: >> is… intriguing. If you follow the code through the function, ts_min in >> the log should always be ts_prev+sys_fuzz; these two values can't be >> identical or differ by any other value, ts_min must strictly be greater >> than ts_prev by sys_fuzz. I notice that there is always a DNS operation >> logged at the same time when I get these errors, so I am pretty sure >> this is related to the DNS thread. That was the case for me _at startup_, but not after that. (See the attached logs.) >> This would also explain why a server >> that has many clients would see many more such errors. Why's that? What DNS lookups is ntpd doing for clients? > While I have not yet identified the code path that is involved (likely > something in NTS, I think), you might want to try the following monkey > patch: > > Let me know if makes a difference on your system. The error crops up > too sparingly on mine to really tell if it helps or not. Attached is what I have right away, filtered for DNS|CLOCK. -- Richard 2019-12-01T02:04:28.211306-06:00 ntp2 ntpd[29868]: DNS: dns_probe: ntp1.wiktel.com, cast_flags:1, flags:21901 2019-12-01T02:04:28.211433-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.46718 s while waiting for another thread 2019-12-01T02:04:28.219010-06:00 ntp2 ntpd[29868]: DNS: dns_check: processing ntp1.wiktel.com, 1, 21901 2019-12-01T02:04:28.219046-06:00 ntp2 ntpd[29868]: DNS: Server taking: 2600:2600::99 2019-12-01T02:04:28.219078-06:00 ntp2 ntpd[29868]: DNS: Server poking hole in restrictions for: 2600:2600::99 2019-12-01T02:04:28.219110-06:00 ntp2 ntpd[29868]: DNS: dns_take_status: ntp1.wiktel.com=>good, 0 2019-12-01T02:04:29.211262-06:00 ntp2 ntpd[29868]: DNS: dns_probe: time.cloudflare.com:1234, cast_flags:1, flags:21901 2019-12-01T02:04:29.211404-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.27831 s while waiting for another thread 2019-12-01T02:04:29.211444-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.08658 s while waiting for another thread 2019-12-01T02:04:29.303891-06:00 ntp2 ntpd[29868]: DNS: dns_check: processing time.cloudflare.com:1234, 1, 21901 2019-12-01T02:04:29.303925-06:00 ntp2 ntpd[29868]: DNS: Server taking: 2606:4700:f1::123 2019-12-01T02:04:29.304008-06:00 ntp2 ntpd[29868]: DNS: Server poking hole in restrictions for: 2606:4700:f1::123 2019-12-01T02:04:29.304055-06:00 ntp2 ntpd[29868]: DNS: dns_take_status: time.cloudflare.com:1234=>good, 0 2019-12-01T02:04:49.271159-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.15647 s while waiting for another thread 2019-12-01T02:05:10.364817-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.08022 s while waiting for another thread 2019-12-01T02:05:37.990619-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.51095 s while waiting for another thread 2019-12-01T02:06:04.152914-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.00160 s while waiting for another thread 2019-12-01T02:06:04.152954-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.01035 s while waiting for another thread 2019-12-01T02:06:20.372082-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.03552 s while waiting for another thread 2019-12-01T02:06:47.079607-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.01632 s while waiting for another thread 2019-12-01T02:06:52.489707-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.24759 s while waiting for another thread 2019-12-01T02:09:59.817856-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.19769 s while waiting for another thread 2019-12-01T02:10:28.192124-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.07581 s while waiting for another thread 2019-12-01T02:10:28.192234-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.22856 s while waiting for another thread 2019-12-01T02:10:41.854610-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.28176 s while waiting for another thread 2019-12-01T02:10:45.901016-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.48026 s while waiting for another thread 2019-12-01T02:10:45.901134-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.03723 s while waiting for another thread 2019-12-01T02:11:22.081163-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.09447 s while waiting for another thread 2019-12-01T02:11:22.081203-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.09033 s while waiting for another thread signature.asc Description: OpenPGP digital signature ___ 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
