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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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 y
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
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
>
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
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
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
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
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
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
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 {} \;
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
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
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
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
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
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
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
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\
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
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
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
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
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 r
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 b
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 yo
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
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
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
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
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
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
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
___
de
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 th
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?
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
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
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,
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
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
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
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
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,
>
>
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 regard
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.
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
+
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
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
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
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
___
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 se
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.
>
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_pps
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.
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
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 st
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 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
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
> ===
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
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
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
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,
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.
(...)
+
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
>
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,
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} %{buildr
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:
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
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
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 419
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
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).
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
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
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
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 +
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
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,
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}\
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 report
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,
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 abou
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
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
>
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 si
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 re
1 - 100 of 145 matches
Mail list logo
