[chrony-dev] chrony-4.6 released

[Miroslav Lichvar]

The final release of chrony-4.6 is now available.

The source code is available here:
https://chrony-project.org/releases/chrony-4.6.tar.gz

SHA256 sum:
9adad4a5014420fc52b695896556fdfb49709dc7cd72d7f688d9eb85d5a274d5

Notable changes:
* Allow disabling pidfile

-- 
Miroslav Lichvar


signature.asc
Description: PGP signature

[chrony-dev] [Git][chrony/chrony] Pushed new tag 4.6

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed new tag 4.6 at chrony / chrony

-- 
View it on GitLab: https://gitlab.com/chrony/chrony/-/tree/4.6
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 7 commits: sources: replace unreachable sources before selection

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
78b9c13a by Miroslav Lichvar at 2024-08-29T09:37:42+02:00
sources: replace unreachable sources before selection

The commit c43efccf0273 ("sources: update source selection with
unreachable sources") caused a high rate of failures in the
148-replacement test (1 falseticker vs 2 unreachable sources). This was
due to a larger fraction of the replacement attempts being made for the
source incorrectly marked as a falseticker instead of the second
unreachable source and the random process needed more time to get to the
expected state with both unreachable sources replaced.

When updating reachability of an unreachable source, try to request the
replacement of the source before calling the source selection, where
other sources may be replaced, to better balance the different
replacement attempts.

- - - - -
bb34e92f by Miroslav Lichvar at 2024-08-29T09:37:50+02:00
test: make 108-peer more reliable

- - - - -
5a6fbe7a by Miroslav Lichvar at 2024-08-29T09:37:50+02:00
test: make 106-refclock more reliable

- - - - -
5a43f0c3 by Miroslav Lichvar at 2024-08-29T09:37:50+02:00
test: make 110-chronyc more reliable

- - - - -
0f5cf57b by Miroslav Lichvar at 2024-08-29T09:37:50+02:00
update copyright years

- - - - -
b363af75 by Miroslav Lichvar at 2024-08-29T09:37:50+02:00
doc: update README

- - - - -
113d1134 by Miroslav Lichvar at 2024-08-29T10:28:49+02:00
doc: update NEWS

- - - - -


18 changed files:

- NEWS
- README
- client.c
- clientlog.c
- cmdmon.c
- doc/chrony.conf.adoc
- doc/faq.adoc
- leapdb.h
- ntp_core.c
- ntp_sources.c
- reference.c
- sources.c
- test/simulation/106-refclock
- test/simulation/108-peer
- test/simulation/110-chronyc
- test/simulation/148-replacement
- test/unit/clientlog.c
- test/unit/leapdb.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/1ab5b88939ba53f592ba4aa7251cc91e032cd32a...113d1134d14e9b5dd8133b934eb853aa7f4f7e38

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/1ab5b88939ba53f592ba4aa7251cc91e032cd32a...113d1134d14e9b5dd8133b934eb853aa7f4f7e38
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 5 commits: doc: clarify hostname with nts option

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
6d592349 by Miroslav Lichvar at 2024-08-20T14:18:54+02:00
doc: clarify hostname with nts option

- - - - -
61f15fed by Miroslav Lichvar at 2024-08-21T11:24:24+02:00
doc: add new question about accuracy to FAQ

- - - - -
08b67dba by Miroslav Lichvar at 2024-08-22T09:32:36+02:00
ntp: fix finalization for async resolver

If an attempt to resolve addresses of an NTP server is made right before
starting the termination sequence, the asynchronous resolver thread
could read the server name when it was already freed.

Leave unresolved sources allocated in NSR_Finalise() if the async
resolver did not finish yet, at least for now. Waiting for the resolving
result or cancelling the thread would complicate the code. The scheduler
is not expected to be running at this point.

- - - - -
e30f937f by Luca Boccassi at 2024-08-22T14:24:49+02:00
doc: explain how to disable DNSSEC validation with sd-resolved in FAQ

DNSSEC requires the system time to be synced in order to work,
as the signature date and expiration need to be checked by
resolvers. But it is possible that syncing the times requires
doing DNS queries. Add a paragraph to the FAQ explaining how
to break this cycle by asking nss-resolved to always avoid
DNSSEC when chronyd tries to resolve hostnames.

- - - - -
1ab5b889 by Luca Boccassi at 2024-08-22T14:24:49+02:00
conf: do not check, write and delete PID file if set to '/'

If the pid file path is specified as '/', skip handling it,
as it is not only unnecessary but complicates managing the
service. A systemd unit can manage the program without any
need for this functionality, and it makes process tracking
simpler and more robust.
The implementation matches the bindcmdaddress directive.

- - - - -


4 changed files:

- conf.c
- doc/chrony.conf.adoc
- doc/faq.adoc
- ntp_sources.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/d4a4f89329f422a7598cd4c5361cbe919aa29a2c...1ab5b88939ba53f592ba4aa7251cc91e032cd32a

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/d4a4f89329f422a7598cd4c5361cbe919aa29a2c...1ab5b88939ba53f592ba4aa7251cc91e032cd32a
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 4 commits: test: extend 008-confload test

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
fd9e956d by Miroslav Lichvar at 2024-08-06T11:27:13+02:00
test: extend 008-confload test

- - - - -
8ba2da52 by Miroslav Lichvar at 2024-08-07T09:46:00+02:00
conf: merge ntp_source_ids with ntp_sources

Keep the configuration IDs of sources loaded from sourcedir in the
NTP_Source structure itself to simplify the code.

- - - - -
916ed70c by Miroslav Lichvar at 2024-08-07T09:48:13+02:00
conf: save source status in sourcedir reload

Save the NSR status when adding a source from a sourcedir and don't
hide sources that failed the addition by clearing their name.

- - - - -
d4a4f893 by Miroslav Lichvar at 2024-08-07T09:48:24+02:00
conf: don't repeat error message when adding sourcedir source

When a source from a configured sourcedir cannot be added (e.g. it is a
duplicate of another source), log the error message only on the first
attempt adding the source, until the source is removed and added to a
sourcedir again.

This avoids spamming of the system log with error messages if the
reload sources command is called frequently (e.g. from a DHCP renewal
networking script).

- - - - -


2 changed files:

- conf.c
- test/system/008-confload


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/43189651b05f3dda954569c981983a849c4170d8...d4a4f89329f422a7598cd4c5361cbe919aa29a2c

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/43189651b05f3dda954569c981983a849c4170d8...d4a4f89329f422a7598cd4c5361cbe919aa29a2c
You're receiving this email because of your account on gitlab.com.

[chrony-dev] chrony-4.6-pre1 released

[Miroslav Lichvar]

The first prerelease for chrony-4.6 is now available.

The source code is available here:
https://chrony-project.org/releases/chrony-4.6-pre1.tar.gz

SHA256 sum:
b155188b0fcf396cc48380e1793a851a2a93fafcfdf4e58ea13a4a761bed59ee

Notable changes since 4.5:

Enhancements

* Add activate option to local directive to set activation threshold
* Add ipv4 and ipv6 options to server/pool/peer directive
* Add kod option to ratelimit directive for server KoD RATE support
* Add leapseclist directive to read NIST/IERS leap-seconds.list file
* Add ptpdomain directive to set PTP domain for NTP over PTP
* Improve copy server option to accept unsynchronised status instantly
* Log one selection failure on start
* Add offset command to modify source offset correction
* Add timestamp sources to ntpdata report

Bug fixes
-
* Fix crash on sources reload during initstepslew or RTC initialisation
* Fix source refreshment to not repeat failed name resolving attempts

-- 
Miroslav Lichvar


signature.asc
Description: PGP signature

[chrony-dev] [Git][chrony/chrony] Pushed new tag 4.6-pre1

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed new tag 4.6-pre1 at chrony / chrony

-- 
View it on GitLab: https://gitlab.com/chrony/chrony/-/tree/4.6-pre1
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 5 commits: leapdb: add explicit cast to int64_t

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
3940d2aa by Miroslav Lichvar at 2024-07-30T12:09:53+02:00
leapdb: add explicit cast to int64_t

Add an explicit cast to int64_t to not rely on LEAP_SEC_LIST_OFFSET
not fitting in 32-bit time_t.

- - - - -
66512ebc by Miroslav Lichvar at 2024-07-30T12:11:09+02:00
ntp: make sure new configuration IDs are unused

The configuration IDs assigned to individual sources (used when they
don't have a resolved IP address) and pools of sources are 32-bit. The
ID could overflow if some sources were very frequently removed and added
again. Two unrelated sources could end up with the same ID, causing some
operations to unexpectedly impact only one or both sources.

Make sure the ID is currently unused before assigning it to a new source.

- - - - -
42b3c40c by Miroslav Lichvar at 2024-07-30T12:11:09+02:00
doc: fix typo in kod option description

- - - - -
f518b8d0 by Miroslav Lichvar at 2024-07-30T12:11:09+02:00
doc: update README

- - - - -
43189651 by Miroslav Lichvar at 2024-07-30T14:05:42+02:00
doc: update NEWS

- - - - -


5 changed files:

- NEWS
- README
- doc/chrony.conf.adoc
- leapdb.c
- ntp_sources.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/34be117c9cc4ea471b13dd009fd2b18db48c8226...43189651b05f3dda954569c981983a849c4170d8

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/34be117c9cc4ea471b13dd009fd2b18db48c8226...43189651b05f3dda954569c981983a849c4170d8
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 2 commits: logging: add function to send message to foreground process

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
7915f524 by Miroslav Lichvar at 2024-07-04T16:50:22+02:00
logging: add function to send message to foreground process

- - - - -
34be117c by Miroslav Lichvar at 2024-07-04T16:50:22+02:00
main: check for killed foreground process

On start, if the foreground process waiting for the daemon process to
close the pipe (after finishing the RTC initialization, initstepslew,
etc) is killed, terminate the daemon too assuming that whatever killed
the foreground process it wanted all chronyd processes to stop.

In the daemon, before closing the pipe file descriptor, send an empty
message to check if the pipe isn't already closed on the other end.

- - - - -


3 changed files:

- logging.c
- logging.h
- main.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/05bd4898a9a64fe1e5432a78939c4b4b82619c2f...34be117c9cc4ea471b13dd009fd2b18db48c8226

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/05bd4898a9a64fe1e5432a78939c4b4b82619c2f...34be117c9cc4ea471b13dd009fd2b18db48c8226
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[SCHNEIDER Johannes]

Hoi Miroslav,


and thanks for the input!
A systemd ExecStartPre in chronyd.service that does this via e.g. 
core-utils:hwclock is a/the workaround...

The proposed opt-in feature (as it is off by default) could IMO still be a good 
fit for chrony, when it is used on (embedded) systems as the sole keeper of the 
RTC.
Thoughts?


gruß
Johannes


From: Miroslav Lichvar 
Sent: Monday, July 1, 2024 10:07
To: SCHNEIDER Johannes
Cc: chrony-dev@chrony.tuxfamily.org
Subject: Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[You don't often get email from mlich...@redhat.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


On Mon, Jul 01, 2024 at 07:50:09AM +, SCHNEIDER Johannes wrote:
> no there wasn't a kernel side discussion;
> On a system where chrony is running it holds the rtc device/file-handle, e.g. 
> has exclusive access and manages the RTC -> there are no other applications 
> reading/handling the RTC.
> So this patch adds the missing "userspace handling" for this uninitialized 
> RTC corner case.

There are other applications supporting RTCs, which other users might
be using, and they would eventually need to handle this corner
case too, right?

To me it seems it's better to handle this in the place that already
has HW-specific code, the driver. If the RTC maintainers reject that
for some reason, then maybe a simple script running on boot using
hwclock.

--
Miroslav Lichvar


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[Miroslav Lichvar]

On Mon, Jul 01, 2024 at 07:50:09AM +, SCHNEIDER Johannes wrote:
> no there wasn't a kernel side discussion;
> On a system where chrony is running it holds the rtc device/file-handle, e.g. 
> has exclusive access and manages the RTC -> there are no other applications 
> reading/handling the RTC.
> So this patch adds the missing "userspace handling" for this uninitialized 
> RTC corner case.

There are other applications supporting RTCs, which other users might
be using, and they would eventually need to handle this corner
case too, right?

To me it seems it's better to handle this in the place that already
has HW-specific code, the driver. If the RTC maintainers reject that
for some reason, then maybe a simple script running on boot using
hwclock.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[SCHNEIDER Johannes]

Hoi,


no there wasn't a kernel side discussion;
On a system where chrony is running it holds the rtc device/file-handle, e.g. 
has exclusive access and manages the RTC -> there are no other applications 
reading/handling the RTC.
So this patch adds the missing "userspace handling" for this uninitialized RTC 
corner case.


gruß
Johannes


From: Miroslav Lichvar 
Sent: Monday, July 1, 2024 09:44
To: chrony-dev@chrony.tuxfamily.org
Subject: Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[You don't often get email from mlich...@redhat.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


On Sun, Jun 30, 2024 at 05:04:00PM +0200, Johannes Schneider wrote:
> Add a configuration option for an "initialization year/timestamp"
> chornyd can use to start an uninitialized RTC, so that the RTC driver
> can continue its start up, and chrony could later trim the RTC to an
> accurate date.
>
> Without this 'kick-off', on systems where the RTC would return -EINVAL
> when being queried either for features, or just being read, chronyd
> would be unable to start the RTC driver ("513 RTC driver not running")
> and hence could/would not set it.
>
> An example RTC where this is the case is RX8130 (of the ds1307
> family), which would return -EINVAL *until* the internal oscillator is
> started by writing a valid date to it.

Wouldn't all applications reading RTC need this patch? I think this
should be addressed in the kernel driver instead. Was there a
discussion about that?

--
Miroslav Lichvar


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[Miroslav Lichvar]

On Sun, Jun 30, 2024 at 05:04:00PM +0200, Johannes Schneider wrote:
> Add a configuration option for an "initialization year/timestamp"
> chornyd can use to start an uninitialized RTC, so that the RTC driver
> can continue its start up, and chrony could later trim the RTC to an
> accurate date.
> 
> Without this 'kick-off', on systems where the RTC would return -EINVAL
> when being queried either for features, or just being read, chronyd
> would be unable to start the RTC driver ("513 RTC driver not running")
> and hence could/would not set it.
> 
> An example RTC where this is the case is RX8130 (of the ds1307
> family), which would return -EINVAL *until* the internal oscillator is
> started by writing a valid date to it.

Wouldn't all applications reading RTC need this patch? I think this
should be addressed in the kernel driver instead. Was there a
discussion about that?

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v1] rtc: handle uninitialized RTC

[Johannes Schneider]

 and could be opened, but is the RTC actually
+ initizlized with a timestamp? e.g. can it be read or does the driver 
return
+ an error because the RTC is in a failure state (the oscilator is not
+ running; the backup batter is dead; it is "factory-fresh" = was never
+ set */
+  status = ioctl(fd, RTC_RD_TIME, &rtc_raw);
+  if ((CNF_GetRtcInitYear() > 0) && (status < 0)) {
+LOG(LOGS_ERR, "initial read of RTC failed, trying an initial write to get 
the oscilator running.");
+/* all other parameter can be 0 - see man 3 gmtime */
+rtc_raw.tm_mday = 1;
+rtc_raw.tm_year = CNF_GetRtcInitYear() - 1900;
+status = ioctl(fd, RTC_SET_TIME, &rtc_raw);
+if (status < 0) {
+  LOG(LOGS_ERR, "initial write to the RTC failed");
+  return 0;
+}
+status = ioctl(fd, RTC_RD_TIME, &rtc_raw);
+if (status < 0) {
+  LOG(LOGS_ERR, "starting the RTC by writing to it failed");
+  return 0;
+}
+LOG(LOGS_INFO, "initialized RTC to %i-01-01", CNF_GetRtcInitYear());
+  }
+
   /* Make sure the RTC supports interrupts */
   if (!switch_interrupts(1) || !switch_interrupts(0)) {
 close(fd);
-- 
2.34.1


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] test: fix 142-ntpoverptp

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
05bd4898 by Miroslav Lichvar at 2024-06-20T15:10:42+02:00
test: fix 142-ntpoverptp

- - - - -


1 changed file:

- test/simulation/142-ntpoverptp


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/05bd4898a9a64fe1e5432a78939c4b4b82619c2f

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/05bd4898a9a64fe1e5432a78939c4b4b82619c2f
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 2 commits: ntp: update NTP-over-PTP support

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
c46e0549 by Miroslav Lichvar at 2024-06-20T14:35:28+02:00
ntp: update NTP-over-PTP support

Following the latest version of the draft, accept NTP messages in both
PTPv2 and PTPv2.1 messages, accept sync messages in addition to delay
request messages, and check the minorSdoId field in PTPv2.1 messages.

Transmitted messages are still PTPv2 delay requests.

Don't switch to the organization-specific TLV yet. Wait for the NTP TLV
subtype and Network Correction extension field to be assigned by IANA to
avoid an additional break in compatibility.

- - - - -
4da088ec by Miroslav Lichvar at 2024-06-20T15:00:17+02:00
ntp: make NTP-over-PTP domain configurable

Add ptpdomain directive to set the domain number of transmitted and
accepted NTP-over-PTP messages. It might need to be changed in networks
using a PTP profile with the same domain number. The default domain
number of 123 follows the current NTP-over-PTP specification.

- - - - -


6 changed files:

- conf.c
- conf.h
- doc/chrony.conf.adoc
- ntp_io.c
- ptp.h
- test/simulation/142-ntpoverptp


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/8f5b3084144967b313cfb51285bf6517e06e1b9e...4da088ec2f153337f2c710a447b232ce797f4b23

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/8f5b3084144967b313cfb51285bf6517e06e1b9e...4da088ec2f153337f2c710a447b232ce797f4b23
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [Git][chrony/chrony][master] 2 commits: doc: clarify prefer source option

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
084fe6b0 by Miroslav Lichvar at 2024-06-04T16:25:55+02:00
doc: clarify prefer source option

- - - - -
8f5b3084 by Miroslav Lichvar at 2024-06-04T16:25:55+02:00
test: make 124-tai more reliable

Reported-by: Reinhard Max 

- - - - -


2 changed files:

- doc/chrony.conf.adoc
- test/simulation/124-tai


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/ebfc676d745545869cbabef55e81e33a94e239ea...8f5b3084144967b313cfb51285bf6517e06e1b9e

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/ebfc676d745545869cbabef55e81e33a94e239ea...8f5b3084144967b313cfb51285bf6517e06e1b9e
You're receiving this email because of your account on gitlab.com.

[chrony-dev] Is 124-tai too sensitive?

[Reinhard Max]

Hi,

we see 124-tai frequently fail on architectures like ppc64le and 
aarch64, but not on x86_64.


The failure happens in is_offset_ok() in reference.c while running the 
first test in 124-tai. On x86_64 fabs(offset) reaches a maximum of 
~0.00098, i.e. it stays just below the 0.001 second limit set by the 
test, whereas on the affected architectures it slightly exceeds the 
limit in most of the test runs, e.g. to 0.0010031337 causing chronyd to 
exit with an error.


I can mitigate this by increasing the allowed offset to cover that 
overshoot, but I am not sure if that would be in accordance with the 
intention of the test.


cu
Reinhard
--
SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom

[Elliott, Robert (Servers)]

The Linux kernel RNG vDSO getrandom() patch series stalled out before, but has
been revived. See "[PATCH v15 0/5] implement getrandom() in vDSO" on
https://lore.kernel.org/lkml/2024052958.2384173-1-ja...@zx2c4.com/


> -Original Message-
> From: Bill Unruh 
> Sent: Tuesday, August 2, 2022 1:59 PM
> To: chrony-dev@chrony.tuxfamily.org
> Subject: Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
> 
> I think it depends on what the purpose of the randomness is. If you need
> real
> cryptgrphic randomness-- ie, unpredictable by an attacker (as for example
> in
> encryption, or signatures) then you have to pay the price in time. If
> however
> what you just want it to have a stream of bytes which does not repeat, so
> that
> two instances will not give the same value (eg uuids or, I suspect filling
> the
> ntp time packets with cruft so that successive packets on time scales less
> than the precision of the clock do not give the same values) then must
> facter
> "random" stream generators would suffice. Calling a cryptogrphic random
> stream
> for the latter would seem to overkill, and much slower than necessary.
> Does
> anyone care if the time stamp bits which are better than the precision are
> predictable by someone outside? Does this give any attacker a attack
> vector?
> In fact it would seem that using a different generator for this purpose
> rather
> than for instances where cryptographic randomness is needed would be an
> advantage in that you would be giving less information about the
> cryptographic
> stream generator to an attacker.
> 
> Of course this is irrelevant prediction  of  the random cruft in the
> timestamps
> gives  an attacker an advantage.
> 
> 
> 
> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
> Canada V6T 1Z1 | and Gravity __|_
> 
> On Tue, 2 Aug 2022, Bill Unruh wrote:
> 
> > Does the added "randomness" need to be crypographically secure or does it 
> > just
> > need to be messed up. Ie is there some attack that someone could lauch 
> > against
> > chrony if they could predict the random stream for that fuzz in the
> > timestamps? If not then using the full force of
> > urandom/getrandom/arc4random
> > would seem expensive overkill. For example using something like A New Class
> > of Random Number Generators
> > George Marsaglia, Arif Zaman
> > Ann. Appl. Probab. 1(3): 462-480 (August, 1991). DOI:
> > 10.1214/aoap/1177005878
> > might be much faster.
> >
> > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> > Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
> > UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
> > Canada V6T 1Z1 | and Gravity __|_
> >
> > On Tue, 2 Aug 2022, Miroslav Lichvar wrote:
> >
> >> On Mon, Aug 01, 2022 at 02:07:53AM +, Elliott, Robert (Servers)
> >> wrote:
> >>> I see the glibc discussion about arc4random has led to a proposal this
> >>> weekend to add a vDSO for the linux kernel's getrandom(). It'll be
> >>> interesting to see if that is accepted - Linus' initial reaction was
> >>> "no".
> >>
> >> I was surprised to see they switched arc4random in glibc to
> >> getrandom(). That has a significant performance impact on chronyd, as
> >> it calls the function for each generated RX and TX timestamp. In my
> >> test the maximum number of requests per second handled as a server
> >> dropped by about 25%. That's not great.
> >>
> >> We'll need to disable the function on Linux, at least until the vDSO
> >> getrandom() is widely available.
> >>
> >> --
> >> Miroslav Lichvar
> >>


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 6 commits: ntp: improve copying of server status

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
27659117 by Miroslav Lichvar at 2024-04-29T11:21:45+02:00
ntp: improve copying of server status

When a server specified with the copy option responds with an
unsynchronized status (e.g. due to selection failure), reset the
source instance to immediately switch the local reference status
instead of waiting for the source to become unreachable after 8 polls.

- - - - -
1affd03c by Miroslav Lichvar at 2024-04-30T15:52:18+02:00
sources: reorder unsynchronised source status

In the source selection, check for the unsynchronized leap status after
getting sourcestats data. The unsynchronized source status is supposed
to indicate an unsynchronized source that is providing samples, not a
source which doesn't have any samples.

Also, fix the comment describing the status.

Fixes: 4c29fc76 ("sources: handle unsynchronized sources in 
selection")

- - - - -
c43efccf by Miroslav Lichvar at 2024-04-30T15:52:18+02:00
sources: update source selection with unreachable sources

When updating the reachability register of a source with zero, call the
source selection even if the source is not the currently selected as the
best source. But do that only if all reachability bits are zero, i.e.
there was no synchronized response for last 8 polls.

This will enable the source selection to log a message when only
unreachable sources are updating reachability and it decreases the
number of unnecessary source selections.

- - - - -
84d6c7a5 by Miroslav Lichvar at 2024-05-02T12:51:38+02:00
sources: allow logging one selection failure on start

Allow one message about failed selection (e.g. no selectable sources)
to be logged before first successful selection when a source has
full-size reachability register (8 polls with a received or missed
response).

This should make it more obvious that chronyd has a wrong configuration
or there is a firewall/networking issue.

- - - - -
adaca0ff by Miroslav Lichvar at 2024-05-02T14:43:46+02:00
reference: switch is_leap_close() from time_t to double

Avoid undefined behavior in the timestamp conversion from double to
time_t in REF_IsLeapSecondClose() with NTP sources configured with a
large offset correction.

- - - - -
ebfc676d by Miroslav Lichvar at 2024-05-02T14:43:51+02:00
ntp: limit offset correction to supported NTP interval

When an NTP source is specified with the offset option, the corrected
offset may get outside of the supported NTP interval (by default -50..86
years around the build date). If the source passed the source selection,
the offset would be rejected only later in the adjustment of the local
clock.

Check the offset validity as part of the NTP test A to make the source
unselectable and make it visible in the measurements log and ntpdata
report.

- - - - -


13 changed files:

- doc/chrony.conf.adoc
- doc/chronyc.adoc
- ntp_core.c
- reference.c
- sources.c
- test/simulation/008-ntpera
- test/simulation/118-maxdelay
- test/simulation/119-smoothtime
- test/simulation/122-xleave
- test/simulation/126-burst
- test/simulation/127-filter
- test/simulation/144-monoroot
- test/system/007-cmdmon


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/989ef702aa75be972af432e1dd0fa2038ebad9a5...ebfc676d745545869cbabef55e81e33a94e239ea

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/989ef702aa75be972af432e1dd0fa2038ebad9a5...ebfc676d745545869cbabef55e81e33a94e239ea
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] Failure of certain simulation tests

[Vincent Blut]

Le 2024-04-25 09:13, Miroslav Lichvar a écrit :
> On Wed, Apr 24, 2024 at 04:46:07PM +0200, Vincent Blut wrote:
> > The failing tests that initiated this thread are now fixed, however 
> > 002-largenetwork
> > still fails though.
> 
> I think that's the arm emulation being too slow and causing timeouts.
> Try setting the CLKNETSIM_CONNECT_TIMEOUT environment variable to 100.

All good now. Thanks a lot Miroslav!

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: [chrony-dev] Failure of certain simulation tests

[Miroslav Lichvar]

On Wed, Apr 24, 2024 at 04:46:07PM +0200, Vincent Blut wrote:
> The failing tests that initiated this thread are now fixed, however 
> 002-largenetwork
> still fails though.

I think that's the arm emulation being too slow and causing timeouts.
Try setting the CLKNETSIM_CONNECT_TIMEOUT environment variable to 100.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Failure of certain simulation tests

[Vincent Blut]

Le 2024-04-24 12:17, Miroslav Lichvar a écrit :
> On Thu, Apr 18, 2024 at 07:07:33PM +0200, Vincent Blut wrote:
> > Le 2024-04-18 17:19, Miroslav Lichvar a écrit :
> > > On Thu, Apr 18, 2024 at 04:06:54PM +0200, Vincent Blut wrote:
> > > > So after building clknetsim with these flags, the same tests are still
> > > > failing (well I guess so because I stopped the execution after 
> > > > 008-ntpera
> > > > has failed since the execution time is so slow on my armhf vm.)
> > > 
> > > Hm, can you please run readelf -sW /usr/sbin/chronyd on this machine?
> > > Maybe there is a new 64-bit specific symbol on this arch that needs to
> > > be covered.
> > 
> > Attached.
> 
> > 62:  0 FUNCGLOBAL DEFAULT  UND 
> > __fstat64_time64@GLIBC_2.34 (4)
> >145:  0 FUNCGLOBAL DEFAULT  UND 
> > __stat64_time64@GLIBC_2.34 (4)
> 
> Missing support for these two caused chronyd and gnutls to
> misinterpret the stat data due to unexpected format. There was also a
> problem with atol() not parsing 64-bit numbers. It should be fixed now
> in git.

The failing tests that initiated this thread are now fixed, however 
002-largenetwork
still fails though.

> Thanks for the report.

You're welcome.


signature.asc
Description: PGP signature

Re: [chrony-dev] Failure of certain simulation tests

[Miroslav Lichvar]

On Thu, Apr 18, 2024 at 07:07:33PM +0200, Vincent Blut wrote:
> Le 2024-04-18 17:19, Miroslav Lichvar a écrit :
> > On Thu, Apr 18, 2024 at 04:06:54PM +0200, Vincent Blut wrote:
> > > So after building clknetsim with these flags, the same tests are still
> > > failing (well I guess so because I stopped the execution after 008-ntpera
> > > has failed since the execution time is so slow on my armhf vm.)
> > 
> > Hm, can you please run readelf -sW /usr/sbin/chronyd on this machine?
> > Maybe there is a new 64-bit specific symbol on this arch that needs to
> > be covered.
> 
> Attached.

> 62:  0 FUNCGLOBAL DEFAULT  UND 
> __fstat64_time64@GLIBC_2.34 (4)
>145:  0 FUNCGLOBAL DEFAULT  UND __stat64_time64@GLIBC_2.34 
> (4)

Missing support for these two caused chronyd and gnutls to
misinterpret the stat data due to unexpected format. There was also a
problem with atol() not parsing 64-bit numbers. It should be fixed now
in git.

Thanks for the report.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Failure of certain simulation tests

[Vincent Blut]

Le 2024-04-18 17:19, Miroslav Lichvar a écrit :
> On Thu, Apr 18, 2024 at 04:06:54PM +0200, Vincent Blut wrote:
> > > The log shows that clknetsim is not built with the -D_LARGEFILE_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 flags. It needs to use the same
> > > time_t as the chronyd binaries.
> > 
> > So after building clknetsim with these flags, the same tests are still
> > failing (well I guess so because I stopped the execution after 008-ntpera
> > has failed since the execution time is so slow on my armhf vm.)
> 
> Hm, can you please run readelf -sW /usr/sbin/chronyd on this machine?
> Maybe there is a new 64-bit specific symbol on this arch that needs to
> be covered.

Attached.
Symbol table '.dynsym' contains 212 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1: 255c 0 SECTION LOCAL  DEFAULT   11 .init
 2: 00034000 0 SECTION LOCAL  DEFAULT   22 .data
 3:  0 FUNCGLOBAL DEFAULT  UND getnameinfo@GLIBC_2.4 (2)
 4:  0 FUNCGLOBAL DEFAULT  UND seccomp_load
 5:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_credentials_set@GNUTLS_3_4 (3)
 6:  0 FUNCGLOBAL DEFAULT  UND freeifaddrs@GLIBC_2.4 (2)
 7:  0 FUNCGLOBAL DEFAULT  UND qsort@GLIBC_2.4 (2)
 8:  0 FUNCGLOBAL DEFAULT  UND pthread_join@GLIBC_2.34 (4)
 9:  0 FUNCGLOBAL DEFAULT  UND sigemptyset@GLIBC_2.4 (2)
10:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_prf_rfc5705@GNUTLS_3_4 (3)
11:  0 FUNCGLOBAL DEFAULT  UND __fcntl_time64@GLIBC_2.34 (4)
12:  0 FUNCGLOBAL DEFAULT  UND strerror@GLIBC_2.4 (2)
13:  0 FUNCGLOBAL DEFAULT  UND inet_ntop@GLIBC_2.4 (2)
14:  0 FUNCGLOBAL DEFAULT  UND mkdir@GLIBC_2.4 (2)
15:  0 FUNCGLOBAL DEFAULT  UND unsetenv@GLIBC_2.4 (2)
16:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_certificate_set_x509_system_trust@GNUTLS_3_4 (3)
17:  0 FUNCGLOBAL DEFAULT  UND geteuid@GLIBC_2.4 (2)
18:  0 FUNCGLOBAL DEFAULT  UND abort@GLIBC_2.4 (2)
19:  0 FUNCGLOBAL DEFAULT  UND connect@GLIBC_2.4 (2)
20:  0 FUNCGLOBAL DEFAULT  UND getsockname@GLIBC_2.4 (2)
21:  0 FUNCGLOBAL DEFAULT  UND random@GLIBC_2.4 (2)
22:  0 FUNCGLOBAL DEFAULT  UND setgroups@GLIBC_2.4 (2)
23:  0 FUNCGLOBAL DEFAULT  UND memcmp@GLIBC_2.4 (2)
24:  0 FUNCGLOBAL DEFAULT  UND __prctl_time64@GLIBC_2.34 (4)
25:  0 FUNCGLOBAL DEFAULT  UND sysconf@GLIBC_2.4 (2)
26:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_record_recv@GNUTLS_3_4 (3)
27:  0 FUNCGLOBAL DEFAULT  UND __isoc99_fscanf@GLIBC_2.7 (5)
28:  0 FUNCGLOBAL DEFAULT  UND exp@GLIBC_2.29 (6)
29:  0 OBJECT  GLOBAL DEFAULT  UND gnutls_free@GNUTLS_3_4 (3)
30:  0 FUNCGLOBAL DEFAULT  UND __sendmsg64@GLIBC_2.34 (4)
31:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_error_is_fatal@GNUTLS_3_4 (3)
32:  0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
33:  0 FUNCGLOBAL DEFAULT  UND gnutls_handshake@GNUTLS_3_4 
(3)
34:  0 FUNCGLOBAL DEFAULT  UND tzset@GLIBC_2.4 (2)
35:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_alpn_set_protocols@GNUTLS_3_4 (3)
36:  0 FUNCGLOBAL DEFAULT  UND __isoc99_sscanf@GLIBC_2.7 (5)
37:  0 FUNCGLOBAL DEFAULT  UND seccomp_init
38:  0 FUNCGLOBAL DEFAULT  UND __mktime64@GLIBC_2.34 (4)
39:  0 FUNCGLOBAL DEFAULT  UND 
nettle_cmac_aes128_digest@NETTLE_8 (7)
40:  0 FUNCGLOBAL DEFAULT  UND socketpair@GLIBC_2.4 (2)
41:  0 FUNCGLOBAL DEFAULT  UND rename@GLIBC_2.4 (2)
42:  0 FUNCGLOBAL DEFAULT  UND strncpy@GLIBC_2.4 (2)
43:  0 FUNCGLOBAL DEFAULT  UND fclose@GLIBC_2.4 (2)
44:  0 FUNCGLOBAL DEFAULT  UND fgets@GLIBC_2.4 (2)
45:  0 FUNCGLOBAL DEFAULT  UND recv@GLIBC_2.4 (2)
46:  0 FUNCGLOBAL DEFAULT  UND getenv@GLIBC_2.4 (2)
47:  0 FUNCGLOBAL DEFAULT  UND __printf_chk@GLIBC_2.4 (2)
48:  0 FUNCGLOBAL DEFAULT  UND seccomp_rule_add
49:  0 FUNCGLOBAL DEFAULT  UND strchr@GLIBC_2.4 (2)
50:  0 FUNCGLOBAL DEFAULT  UND strcasecmp@GLIBC_2.4 (2)
51:  0 FUNCGLOBAL DEFAULT  UND __cxa_atexit@GLIBC_2.4 (2)
52:  0 FUNCGLOBAL DEFAULT  UND pclose@GLIBC_2.4 (2)
53:  0 FUNCGLOBAL DEFAULT  UND listen@GLIBC_2.4 (2)
54:  0 FUNCGLOBAL DEFAULT  UND cap_set_proc
55:  0 FUNCGLOBAL DEFAULT  UND 
gnutls_sessi

Re: [chrony-dev] Failure of certain simulation tests

[Miroslav Lichvar]

On Thu, Apr 18, 2024 at 04:06:54PM +0200, Vincent Blut wrote:
> > The log shows that clknetsim is not built with the -D_LARGEFILE_SOURCE
> > -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 flags. It needs to use the same
> > time_t as the chronyd binaries.
> 
> So after building clknetsim with these flags, the same tests are still
> failing (well I guess so because I stopped the execution after 008-ntpera
> has failed since the execution time is so slow on my armhf vm.)

Hm, can you please run readelf -sW /usr/sbin/chronyd on this machine?
Maybe there is a new 64-bit specific symbol on this arch that needs to
be covered.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Failure of certain simulation tests

[Vincent Blut]

Hi,

Le 2024-04-16 08:08, Miroslav Lichvar a écrit :
> On Tue, Apr 16, 2024 at 12:25:53AM +0200, Vincent Blut wrote:
> > I have yet to set up an armhf based environment to properly debug those 
> > failures,
> > but the most likely cause seems to be the ongoing migration of our
> > 32-bits architectures to 64-bits time_t. If so, do you have an idea
> > about where the problem lies?
> 
> > ¹ https://ci.debian.net/packages/c/chrony/unstable/armhf/45199616/#S6
> 
> The log shows that clknetsim is not built with the -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 flags. It needs to use the same
> time_t as the chronyd binaries.

So after building clknetsim with these flags, the same tests are still
failing (well I guess so because I stopped the execution after 008-ntpera
has failed since the execution time is so slow on my armhf vm.)

Something new though, the 002-largenetwork test now fails too.
make: Entering directory '/tmp/autopkgtest-lxc.twwwe2ae/downtmp/autopkgtest_tmp'
cc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -O2 -Wall -g 
-fPIC -DGETTIMEOFDAY_VOID  -c -o client.o client.c
In file included from sysheaders.h:16,
 from protocol.h:21,
 from client.c:68:
client.c: In function ‘clock_settime’:
client.c:970:16: warning: ‘nonnull’ argument ‘tp’ compared to NULL 
[-Wnonnull-compare]
  970 | assert(tp && which_clock == CLOCK_REALTIME);
  |^~
client.c: In function ‘poll’:
client.c:1295:27: warning: ‘*.fd’ may be used uninitialized 
[-Wmaybe-uninitialized]
 1295 | if (fds[i].fd < 0)
  | ~~^~~
client.c:1284:25: note: accessing argument 1 of a function declared with 
attribute ‘access (write_only, 1, 2)’
 1284 | int poll(struct pollfd *fds, nfds_t nfds, int timeout) {
  |  ~~~^~~
cc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -O2 -Wall -g 
-fPIC -shared -o clknetsim.so client.o  -ldl -lm
g++ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -O2 -Wall -g 
-fPIC -DGETTIMEOFDAY_VOID  -c -o clock.o clock.cc
g++ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -O2 -Wall -g 
-fPIC -DGETTIMEOFDAY_VOID  -c -o generator.o generator.cc
g++ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -O2 -Wall -g 
-fPIC -DGETTIMEOFDAY_VOID  -c -o network.o network.cc
In file included from /usr/include/c++/13/map:62,
 from generator.h:23,
 from clock.h:23,
 from node.h:22,
 from network.h:26,
 from network.cc:19:
/usr/include/c++/13/bits/stl_tree.h: In function ‘std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::_M_emplace_hint_unique(const_iterator, _Args&& ...) [with 
_Args = {const std::piecewise_construct_t&, 
std::tuple, 
std::allocator >&&>, std::tuple<>}; _Key = 
std::__cxx11::basic_string; _Val = std::pair, double>; _KeyOfValue = 
std::_Select1st, double> >; 
_Compare = std::less >; _Alloc = 
std::allocator, double> >]’:
/usr/include/c++/13/bits/stl_tree.h:2458:7: note: parameter passing for 
argument of type ‘std::_Rb_tree, 
std::pair, double>, 
std::_Select1st, double> >, 
std::less >, std::allocator, double> > >::const_iterator’ changed in GCC 
7.1
 2458 |   _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
  |   ^~~
In file included from /usr/include/c++/13/map:63:
In member function ‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& 
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](key_type&&) [with _Key = 
std::__cxx11::basic_string; _Tp = double; _Compare = 
std::less >; _Alloc = 
std::allocator, double> >]’,
inlined from ‘void Network::send(Packet*)’ at network.cc:409:30:
/usr/include/c++/13/bits/stl_map.h:532:44: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::pair, double>, std::_Select1st, double> >, 
std::less >, std::allocator, double> > >::const_iterator’ changed in GCC 
7.1
  532 |   __i = _M_t._M_emplace_hint_unique(__i, 
std::piecewise_construct,
  | 
~~~^~~
  533 | 
std::forward_as_tuple(std::move(__k)),
  | 
~~
  534 | std::tuple<>());
  | ~~~
In member function ‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& 
std::map<_Key, _Tp, _Compare, _Alloc>::operator[](key_type&&) [with _Key = 
std::__cxx11::basic_string; _Tp = double; _Compare = 
std::less >; _Alloc = 
std::allocator, double> >]’,
inlined from ‘void Network::send(Packet*)’ at network.cc:410:30:
/usr/include/c++/13/bits/stl_map.h:532:44: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::pair, doub

[chrony-dev] [Git][chrony/chrony][master] 2 commits: doc: fix typo in chronyc docs

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
1920b1ef by Rob Gill at 2024-04-16T07:49:59+02:00
doc: fix typo in chronyc docs

Typo fix only - no change to content

Signed-off-by: Rob Gill 

- - - - -
989ef702 by Rob Gill at 2024-04-16T07:50:11+02:00
doc: fix typo in README

Typo correction only - no change to content

Signed-off-by: Rob Gill 

- - - - -


2 changed files:

- README
- doc/chronyc.adoc


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/bb5db828c60adc0325bae33febd2befb3ecb2662...989ef702aa75be972af432e1dd0fa2038ebad9a5

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/bb5db828c60adc0325bae33febd2befb3ecb2662...989ef702aa75be972af432e1dd0fa2038ebad9a5
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] Failure of certain simulation tests

[Miroslav Lichvar]

On Tue, Apr 16, 2024 at 12:25:53AM +0200, Vincent Blut wrote:
> I have yet to set up an armhf based environment to properly debug those 
> failures,
> but the most likely cause seems to be the ongoing migration of our
> 32-bits architectures to 64-bits time_t. If so, do you have an idea
> about where the problem lies?

> ¹ https://ci.debian.net/packages/c/chrony/unstable/armhf/45199616/#S6

The log shows that clknetsim is not built with the -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 flags. It needs to use the same
time_t as the chronyd binaries.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] Failure of certain simulation tests

[Vincent Blut]

Hi Miroslav,

I'm experiencing some issues with 4 simulation tests¹ on the armel and armhf
architectures:

SUMMARY:
   TOTAL  63
   PASSED 59
   FAILED 4(008-ntpera 115-cmdmontime 139-nts 145-rtc) (24508 24508 24508 
24508)
   SKIPPED 0   ()

I have yet to set up an armhf based environment to properly debug those 
failures,
but the most likely cause seems to be the ongoing migration of our
32-bits architectures to 64-bits time_t. If so, do you have an idea
about where the problem lies?

Cheers,
Vincent

¹ https://ci.debian.net/packages/c/chrony/unstable/armhf/45199616/#S6


signature.asc
Description: PGP signature

[chrony-dev] [Git][chrony/chrony][master] ntp: log failed connection to Samba signd socket

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
bb5db828 by Miroslav Lichvar at 2024-04-15T16:35:33+02:00
ntp: log failed connection to Samba signd socket

Log an error message (in addition to the socket-specific debug message)
when the connection to signd socket fails, but only once before a
successful signd exchange to avoid flooding the system log.

- - - - -


1 changed file:

- ntp_signd.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/bb5db828c60adc0325bae33febd2befb3ecb2662

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/bb5db828c60adc0325bae33febd2befb3ecb2662
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] gitlab patch notification to list

[Bryan Christianson]

Sorry about that - I hadn't realised that this was caused by issues at 
tuxfamily.org

> On 8 Apr 2024, at 08:39, Bryan Christianson  wrote:
> 
> I just refreshed my local copy of chrony and noticed I was a couple of weeks 
> behind in patches. Prior to the move to gitlab this list received 
> notifications of updates to the git repository.
> 
> Is it possible to re-instate this behaviour? Not a necessity I guess, but 
> definitely a convenience.
> 
> Regards, Bryan
> 
> -- 
> Bryan Christianson
> br...@whatroute.net
> 
> 
> 
> 
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with 
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
> 

Bryan Christianson
br...@whatroute.net




--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] gitlab patch notification to list

[Bryan Christianson]

I just refreshed my local copy of chrony and noticed I was a couple of weeks 
behind in patches. Prior to the move to gitlab this list received notifications 
of updates to the git repository.

Is it possible to re-instate this behaviour? Not a necessity I guess, but 
definitely a convenience.

Regards, Bryan

-- 
Bryan Christianson
br...@whatroute.net




--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 5 commits: refclock: update comment in PHC driver

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
28e4eec1 by Miroslav Lichvar at 2024-04-10T12:13:29+02:00
refclock: update comment in PHC driver

Since Linux 6.7 external timestamping events are no longer shared among
all descriptors of a PHC. Each descriptor gets its own copy of each
timestamp.

- - - - -
a914140b by Miroslav Lichvar at 2024-04-10T15:33:04+02:00
sys_linux: disable other external timestamping channels

Use new ioctls added in Linux 6.7 to disable receiving events from other
channels when enabling external timestamping on a PHC. This should save
some CPU time when other applications or chronyd instances are using
other channels of the same PHC.

- - - - -
342b588e by Miroslav Lichvar at 2024-04-11T10:31:02+02:00
avoid some static analysis errors

Modify the code to avoid some false positives reported by the clang and
gcc static analyzers.

- - - - -
2ed72c49 by Miroslav Lichvar at 2024-04-11T12:53:01+02:00
test: add --enable-debug option to 002-scanbuild

- - - - -
dcc94a4c by Miroslav Lichvar at 2024-04-11T16:52:06+02:00
doc: add contributing.adoc

- - - - -


7 changed files:

- + doc/contributing.adoc
- refclock_phc.c
- regress.c
- sourcestats.c
- sys_linux.c
- tempcomp.c
- test/compilation/002-scanbuild


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/5235c51801941753b9d050d646c9fba9842b3959...dcc94a4c101670e54c2da9142ef082eed6d68abd

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/5235c51801941753b9d050d646c9fba9842b3959...dcc94a4c101670e54c2da9142ef082eed6d68abd
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] [PATCH] local threshold option

[Andy Fiddaman]

On Fri, 29 Mar 2024, Andy Fiddaman wrote:

>
> On Thu, 28 Mar 2024, Miroslav Lichvar wrote:
>
> > On Mon, Mar 25, 2024 at 07:10:31PM +, Andy Fiddaman wrote:
> > > How does the attached patch look? This adds `local threshold` as you
> > > suggested, that defaults to 0 which means it is not used. If it's set,
> > > then the local reference is not activated until the root distance drops
> > > below the value once.
> > >
> > > In our configuration, we can then use something like:
> > >
> > > local stratum 10 distance 1.0 threshold 1.0
> >
> > The distance option is already described as a threshold, so I think a
> > different name might work better. How about trigger, start or activate?
>
> I like 'activate', that's much clearer.
>
> > Let's think a bit about possible future options. We might need a
> > timeout-based activation, e.g. wait for 10 minutes before activating
> > local. It could be a second parameter of this option or a separate
> > option. What naming would be most consistent?
>
> If such things were required, I think it would probably be better
> to group them with 'activate'; as in having the timer as an extra
> parameter. It's hard to predict what might be needed in the future
> though. The same goes for the potential padding of the local
> control message.
>
> I've attached the latest patch.
>
> I'm happy to go back and do something here if you'd like, but also
> please feel free to adjust what I've done here to better fit the
> goals of the project.

The last patch was missing a couple of things, and did not preserve support
for older clients that might be using REQ_LOCAL2. I've updated the patch
to address those.

Andy
From 9083a01a09d2cbae80669feccb0e2a29e200e980 Mon Sep 17 00:00:00 2001
From: Andy Fiddaman 
Date: Mon, 25 Mar 2024 19:05:52 +
Subject: [PATCH] Add "local activate" option

---
 candm.h  |  4 +++-
 client.c |  7 ---
 cmdmon.c | 12 
 cmdparse.c   |  6 +-
 cmdparse.h   |  2 +-
 conf.c   |  6 --
 conf.h   |  2 +-
 doc/chrony.conf.adoc | 21 ++---
 pktlength.c  |  3 ++-
 reference.c  | 21 +++--
 reference.h  |  2 +-
 11 files changed, 58 insertions(+), 28 deletions(-)

diff --git a/candm.h b/candm.h
index 0894ad5..b4e41f1 100644
--- a/candm.h
+++ b/candm.h
@@ -111,7 +111,8 @@
 #define REQ_DOFFSET2 71
 #define REQ_MODIFY_SELECTOPTS 72
 #define REQ_MODIFY_OFFSET 73
-#define N_REQUEST_TYPES 74
+#define REQ_LOCAL3 74
+#define N_REQUEST_TYPES 75
 
 /* Structure used to exchange timespecs independent of time_t size */
 typedef struct {
@@ -237,6 +238,7 @@ typedef struct {
   int32_t stratum;
   Float distance;
   int32_t orphan;
+  Float activate;
   int32_t EOR;
 } REQ_Local;
 
diff --git a/client.c b/client.c
index 0231b9e..a1e213f 100644
--- a/client.c
+++ b/client.c
@@ -755,22 +755,23 @@ static int
 process_cmd_local(CMD_Request *msg, char *line)
 {
   int on_off, stratum = 0, orphan = 0;
-  double distance = 0.0;
+  double distance = 0.0, activate = 0.0;
 
   if (!strcmp(line, "off")) {
 on_off = 0;
-  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance)) {
+  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance, &activate)) {
 on_off = 1;
   } else {
 LOG(LOGS_ERR, "Invalid syntax for local command");
 return 0;
   }
 
-  msg->command = htons(REQ_LOCAL2);
+  msg->command = htons(REQ_LOCAL3);
   msg->data.local.on_off = htonl(on_off);
   msg->data.local.stratum = htonl(stratum);
   msg->data.local.distance = UTI_FloatHostToNetwork(distance);
   msg->data.local.orphan = htonl(orphan);
+  msg->data.local.activate = UTI_FloatHostToNetwork(activate);
 
   return 1;
 }
diff --git a/cmdmon.c b/cmdmon.c
index 716775f..8d7d7e5 100644
--- a/cmdmon.c
+++ b/cmdmon.c
@@ -146,6 +146,7 @@ static const char permissions[] = {
   PERMIT_AUTH, /* DOFFSET2 */
   PERMIT_AUTH, /* MODIFY_SELECTOPTS */
   PERMIT_AUTH, /* MODIFY_OFFSET */
+  PERMIT_AUTH, /* LOCAL3 */
 };
 
 /* == */
@@ -526,12 +527,14 @@ handle_settime(CMD_Request *rx_message, CMD_Reply 
*tx_message)
 /* == */
 
 static void
-handle_local(CMD_Request *rx_message, CMD_Reply *tx_message)
+handle_local(CMD_Request *rx_message, CMD_Reply *tx_message, uint16_t cmd)
 {
   if (ntohl(rx_message->data.local.on_off)) {
 REF_EnableLocal(ntohl(rx_message->data.local.stratum),
 UTI_FloatNetworkToHost(rx_message->data.local.distance),
-ntohl(rx_message->data.local.orphan));
+ntohl(rx_message->data.local.orphan),
+cmd == REQ_LOCAL2 ? 0 :
+UTI_FloatNetworkToHost(rx_message->data.local.activate));
   } else {
 REF_DisableLocal();
   }
@@ -1648,9 +1651,10 @@ read_from_cmd_socket(int sock_fd, int event, void 
*anything)
 case REQ_SETTIME:
   hand

Re: [chrony-dev] [PATCH] local threshold option

[Miroslav Lichvar]

On Fri, Mar 29, 2024 at 01:44:34AM +, Andy Fiddaman wrote:
> I've attached the latest patch.
> 
> I'm happy to go back and do something here if you'd like, but also
> please feel free to adjust what I've done here to better fit the
> goals of the project.

I applied the patch with some fixes. I hope that's ok.

> @@ -1648,8 +1650,8 @@ read_from_cmd_socket(int sock_fd, int event, void 
> *anything)
>  case REQ_SETTIME:
>handle_settime(&rx_message, &tx_message);
>break;
> -
> -case REQ_LOCAL2:
> +
> +case REQ_LOCAL3:
>handle_local(&rx_message, &tx_message);
>break;

The corresponding change is missing in client.c

>/* Local reference is active when enabled and the clock is not synchronised
>   or the root distance exceeds the threshold */
> -
>if (are_we_synchronised &&
> -  !(enable_local_stratum && our_root_delay / 2 + dispersion > 
> local_distance)) {
> +  !(enable_local_stratum && distance > local_distance)) {

This is missing local_activate_ok to prevent unsynchronized status
when the distance check passes but activation not. I added some tests
for that in a separate commit, so hopefully it works as expected.
>  
>  *is_synchronised = 1;
>  
> @@ -1158,7 +1166,7 @@ REF_GetReferenceParams
>  *root_delay = our_root_delay;
>  *root_dispersion = dispersion;
>  
> -  } else if (enable_local_stratum) {
> +  } else if (enable_local_stratum && local_activate_ok) {
>  
>  *is_synchronised = 0;
>  

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 8 commits: nts: check for NTS NAK specifically when responding

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
ce956c99 by Miroslav Lichvar at 2024-04-02T11:33:04+02:00
nts: check for NTS NAK specifically when responding

Ignore other KoD codes than NTS NAK when deciding if the server response
should not be authenticated.

- - - - -
c8c7f518 by Miroslav Lichvar at 2024-04-02T11:55:02+02:00
clientlog: return enum from CLG_LimitServiceRate()

Change CLG_LimitServiceRate() to return an enum in preparation for
adding KoD RATE support.

- - - - -
aac89834 by Miroslav Lichvar at 2024-04-02T15:23:26+02:00
clientlog: add support for KoD rate limiting

Add a third return value to CLG_LimitServiceRate() to indicate the
server should send a response requesting the client to reduce its
polling rate. It randomly selects from a fraction (configurable to 1/2,
1/4, 1/8, 1/16, or disabled) of responses which would be dropped
(after selecting responses for the leak option).

- - - - -
24d28cd6 by Miroslav Lichvar at 2024-04-02T15:39:12+02:00
ntp: add server support for KoD RATE

Add "kod" option to the ratelimit directive to respond with the KoD
RATE code to randomly selected requests exceeding the configured limit.
This complements the client support of KoD RATE. It's disabled by
default.

There can be only one KoD code in one response. If both NTS NAK and RATE
codes are triggered, drop the response. The KoD RATE code can be set in
an NTS-authenticated response.

- - - - -
b8ead348 by Miroslav Lichvar at 2024-04-03T11:01:44+02:00
leapdb: fix leapsec list processing with 32-bit time_t

A 32-bit time_t value overflows when converted to the Y1900 epoch used
in the leapsec list. Use a 64-bit variable in get_list_leap() to fix the
comparisons on systems using 32-bit time_t.

Fixes: 53823b9f1c07 ("leapdb: support leap-seconds.list as second 
source")

- - - - -
9397ae2b by Andy Fiddaman at 2024-04-04T15:17:05+02:00
reference: add "local activate" option

This option sets an activating root distance for the local reference. The
local reference will not be used until the root distance drops below the
configured value for the first time. This can be used to prevent the local
reference from being activated on a server which has never been synchronised
with an upstream server. The default value of 0.0 causes no activating
distance to be used, such that the local reference is always eligible for
activation.

- - - - -
26ea4e35 by Miroslav Lichvar at 2024-04-04T16:24:02+02:00
test: add tests of local directive options

- - - - -
5235c518 by Miroslav Lichvar at 2024-04-04T16:24:43+02:00
cmdmon: add reserved fields to local command

Add two reserved fields initialized to zero to the new REQ_LOCAL3
command to allow adding more options (e.g. delay in activation) without
changing the command number again.

- - - - -


22 changed files:

- candm.h
- client.c
- clientlog.c
- clientlog.h
- cmdmon.c
- cmdparse.c
- cmdparse.h
- conf.c
- conf.h
- doc/chrony.conf.adoc
- leapdb.c
- ntp_core.c
- nts_ke_server.c
- nts_ntp_server.c
- pktlength.c
- reference.c
- reference.h
- test/simulation/110-chronyc
- + test/simulation/121-local
- − test/simulation/121-orphan
- test/simulation/135-ratelimit
- test/unit/clientlog.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/863866354d058554e691959870770a8a07350431...5235c51801941753b9d050d646c9fba9842b3959

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/863866354d058554e691959870770a8a07350431...5235c51801941753b9d050d646c9fba9842b3959
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] [PATCH] local threshold option

[Andy Fiddaman]

On Thu, 28 Mar 2024, Miroslav Lichvar wrote:

> On Mon, Mar 25, 2024 at 07:10:31PM +, Andy Fiddaman wrote:
> > How does the attached patch look? This adds `local threshold` as you
> > suggested, that defaults to 0 which means it is not used. If it's set,
> > then the local reference is not activated until the root distance drops
> > below the value once.
> >
> > In our configuration, we can then use something like:
> >
> > local stratum 10 distance 1.0 threshold 1.0
>
> The distance option is already described as a threshold, so I think a
> different name might work better. How about trigger, start or activate?

I like 'activate', that's much clearer.

> Let's think a bit about possible future options. We might need a
> timeout-based activation, e.g. wait for 10 minutes before activating
> local. It could be a second parameter of this option or a separate
> option. What naming would be most consistent?

If such things were required, I think it would probably be better
to group them with 'activate'; as in having the timer as an extra
parameter. It's hard to predict what might be needed in the future
though. The same goes for the potential padding of the local
control message.

I've attached the latest patch.

I'm happy to go back and do something here if you'd like, but also
please feel free to adjust what I've done here to better fit the
goals of the project.

Thanks,

Andy
From 299716042e487bbc7203322243769ff81526052d Mon Sep 17 00:00:00 2001
From: Andy Fiddaman 
Date: Mon, 25 Mar 2024 19:05:52 +
Subject: [PATCH] Add "local activate" option

---
 candm.h  |  4 +++-
 client.c |  5 +++--
 cmdmon.c |  8 +---
 cmdparse.c   |  6 +-
 cmdparse.h   |  2 +-
 conf.c   |  6 --
 conf.h   |  2 +-
 doc/chrony.conf.adoc | 21 ++---
 pktlength.c  |  3 ++-
 reference.c  | 21 +++--
 reference.h  |  2 +-
 11 files changed, 54 insertions(+), 26 deletions(-)

diff --git a/candm.h b/candm.h
index 0894ad5..b4e41f1 100644
--- a/candm.h
+++ b/candm.h
@@ -111,7 +111,8 @@
 #define REQ_DOFFSET2 71
 #define REQ_MODIFY_SELECTOPTS 72
 #define REQ_MODIFY_OFFSET 73
-#define N_REQUEST_TYPES 74
+#define REQ_LOCAL3 74
+#define N_REQUEST_TYPES 75
 
 /* Structure used to exchange timespecs independent of time_t size */
 typedef struct {
@@ -237,6 +238,7 @@ typedef struct {
   int32_t stratum;
   Float distance;
   int32_t orphan;
+  Float activate;
   int32_t EOR;
 } REQ_Local;
 
diff --git a/client.c b/client.c
index 0231b9e..1893df7 100644
--- a/client.c
+++ b/client.c
@@ -755,11 +755,11 @@ static int
 process_cmd_local(CMD_Request *msg, char *line)
 {
   int on_off, stratum = 0, orphan = 0;
-  double distance = 0.0;
+  double distance = 0.0, activate = 0.0;
 
   if (!strcmp(line, "off")) {
 on_off = 0;
-  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance)) {
+  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance, &activate)) {
 on_off = 1;
   } else {
 LOG(LOGS_ERR, "Invalid syntax for local command");
@@ -771,6 +771,7 @@ process_cmd_local(CMD_Request *msg, char *line)
   msg->data.local.stratum = htonl(stratum);
   msg->data.local.distance = UTI_FloatHostToNetwork(distance);
   msg->data.local.orphan = htonl(orphan);
+  msg->data.local.activate = UTI_FloatHostToNetwork(activate);
 
   return 1;
 }
diff --git a/cmdmon.c b/cmdmon.c
index 716775f..aaf6996 100644
--- a/cmdmon.c
+++ b/cmdmon.c
@@ -146,6 +146,7 @@ static const char permissions[] = {
   PERMIT_AUTH, /* DOFFSET2 */
   PERMIT_AUTH, /* MODIFY_SELECTOPTS */
   PERMIT_AUTH, /* MODIFY_OFFSET */
+  PERMIT_AUTH, /* LOCAL3 */
 };
 
 /* == */
@@ -531,7 +532,8 @@ handle_local(CMD_Request *rx_message, CMD_Reply *tx_message)
   if (ntohl(rx_message->data.local.on_off)) {
 REF_EnableLocal(ntohl(rx_message->data.local.stratum),
 UTI_FloatNetworkToHost(rx_message->data.local.distance),
-ntohl(rx_message->data.local.orphan));
+ntohl(rx_message->data.local.orphan),
+UTI_FloatNetworkToHost(rx_message->data.local.activate));
   } else {
 REF_DisableLocal();
   }
@@ -1648,8 +1650,8 @@ read_from_cmd_socket(int sock_fd, int event, void 
*anything)
 case REQ_SETTIME:
   handle_settime(&rx_message, &tx_message);
   break;
-
-case REQ_LOCAL2:
+
+case REQ_LOCAL3:
   handle_local(&rx_message, &tx_message);
   break;
 
diff --git a/cmdparse.c b/cmdparse.c
index 0a80fc0..77447dc 100644
--- a/cmdparse.c
+++ b/cmdparse.c
@@ -296,13 +296,14 @@ CPS_ParseAllowDeny(char *line, int *all, IPAddr *ip, int 
*subnet_bits)
 /* == */
 
 int
-CPS_ParseLocal(char *line, int *stratum, int *orphan, double *distance)
+CPS_ParseLocal(char *line, int *stratum, int *orphan, double *distance, double 
*

Re: [chrony-dev] [PATCH] local threshold option

[Miroslav Lichvar]

On Mon, Mar 25, 2024 at 07:10:31PM +, Andy Fiddaman wrote:
> How does the attached patch look? This adds `local threshold` as you
> suggested, that defaults to 0 which means it is not used. If it's set,
> then the local reference is not activated until the root distance drops
> below the value once.
> 
> In our configuration, we can then use something like:
> 
> local stratum 10 distance 1.0 threshold 1.0

The distance option is already described as a threshold, so I think a
different name might work better. How about trigger, start or activate?

Let's think a bit about possible future options. We might need a
timeout-based activation, e.g. wait for 10 minutes before activating
local. It could be a second parameter of this option or a separate
option. What naming would be most consistent?

> --- a/candm.h
> +++ b/candm.h
> @@ -237,6 +237,7 @@ typedef struct {
>int32_t stratum;
>Float distance;
>int32_t orphan;
> +  Float threshold;
>int32_t EOR;
>  } REQ_Local;

This is an incompatible change in the request, so there should be also
a new code defined (REQ_LOCAL3). You could also add a few reserved
fields to the command, so next time it could keep the code if the
original behavior is preserved by interpreting the old reserved
field.

> @@ -1699,6 +1699,11 @@ An example of the directive is:
>  
>  local stratum 10 orphan distance 0.1
>  
> +*threshold* _distance_:::
> +This option sets an activating threshold for the local reference. The local
> +reference will not be used until the root distance drops below the configured
> +threshold once. This can be used to prevent the local reference being 
> activated
> +on a server which has never been synchronised with an upstream server.

This should mention the special value of 0 and that it is the default.

> @@ -1158,7 +1163,11 @@ REF_GetReferenceParams
>  *root_delay = our_root_delay;
>  *root_dispersion = dispersion;
>  
> -  } else if (enable_local_stratum) {
> +if (distance > 0 && distance < local_threshold)
> +  local_threshold_met = 1;

This should be earlier in the function so the new condition below can
trigger on the first pass?

> +
> +  } else if (enable_local_stratum &&
> + (local_threshold == 0 || local_threshold_met)) {

Please use 0.0 in places where a floating-point variable is compared.

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH] local threshold option

[Andy Fiddaman]

On Thu, 21 Mar 2024, Miroslav Lichvar wrote:

> > The first, "local oncesynced" prevents the local reference being activated
> > unless time was synchronised at some point in the past.
>
> This makes sense to me, although I think it might be better to
> generalize it as an activating root distance, which would completement
> the distance option (threshold).

How does the attached patch look? This adds `local threshold` as you
suggested, that defaults to 0 which means it is not used. If it's set,
then the local reference is not activated until the root distance drops
below the value once.

In our configuration, we can then use something like:

local stratum 10 distance 1.0 threshold 1.0

Thanks,

Andy
From d094cb53ab1632fc741cb60cf92520e9d3c84880 Mon Sep 17 00:00:00 2001
From: Andy Fiddaman 
Date: Mon, 25 Mar 2024 19:05:52 +
Subject: [PATCH] Add "local threshold" option

---
 candm.h  |  1 +
 client.c |  5 +++--
 cmdmon.c |  3 ++-
 cmdparse.c   |  6 +-
 cmdparse.h   |  2 +-
 conf.c   |  6 --
 conf.h   |  2 +-
 doc/chrony.conf.adoc |  5 +
 reference.c  | 22 --
 reference.h  |  2 +-
 10 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/candm.h b/candm.h
index 0894ad5..64e3200 100644
--- a/candm.h
+++ b/candm.h
@@ -237,6 +237,7 @@ typedef struct {
   int32_t stratum;
   Float distance;
   int32_t orphan;
+  Float threshold;
   int32_t EOR;
 } REQ_Local;
 
diff --git a/client.c b/client.c
index 0231b9e..0674263 100644
--- a/client.c
+++ b/client.c
@@ -755,11 +755,11 @@ static int
 process_cmd_local(CMD_Request *msg, char *line)
 {
   int on_off, stratum = 0, orphan = 0;
-  double distance = 0.0;
+  double distance = 0.0, threshold = 0.0;
 
   if (!strcmp(line, "off")) {
 on_off = 0;
-  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance)) {
+  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance, &threshold)) {
 on_off = 1;
   } else {
 LOG(LOGS_ERR, "Invalid syntax for local command");
@@ -771,6 +771,7 @@ process_cmd_local(CMD_Request *msg, char *line)
   msg->data.local.stratum = htonl(stratum);
   msg->data.local.distance = UTI_FloatHostToNetwork(distance);
   msg->data.local.orphan = htonl(orphan);
+  msg->data.local.threshold = UTI_FloatHostToNetwork(threshold);
 
   return 1;
 }
diff --git a/cmdmon.c b/cmdmon.c
index 716775f..464aeb5 100644
--- a/cmdmon.c
+++ b/cmdmon.c
@@ -531,7 +531,8 @@ handle_local(CMD_Request *rx_message, CMD_Reply *tx_message)
   if (ntohl(rx_message->data.local.on_off)) {
 REF_EnableLocal(ntohl(rx_message->data.local.stratum),
 UTI_FloatNetworkToHost(rx_message->data.local.distance),
-ntohl(rx_message->data.local.orphan));
+ntohl(rx_message->data.local.orphan),
+UTI_FloatNetworkToHost(rx_message->data.local.threshold));
   } else {
 REF_DisableLocal();
   }
diff --git a/cmdparse.c b/cmdparse.c
index 0a80fc0..d811948 100644
--- a/cmdparse.c
+++ b/cmdparse.c
@@ -296,13 +296,14 @@ CPS_ParseAllowDeny(char *line, int *all, IPAddr *ip, int 
*subnet_bits)
 /* == */
 
 int
-CPS_ParseLocal(char *line, int *stratum, int *orphan, double *distance)
+CPS_ParseLocal(char *line, int *stratum, int *orphan, double *distance, double 
*threshold)
 {
   int n;
   char *cmd;
 
   *stratum = 10;
   *distance = 1.0;
+  *threshold = 0.0;
   *orphan = 0;
 
   while (*line) {
@@ -319,6 +320,9 @@ CPS_ParseLocal(char *line, int *stratum, int *orphan, 
double *distance)
 } else if (!strcasecmp(cmd, "distance")) {
   if (sscanf(line, "%lf%n", distance, &n) != 1)
 return 0;
+} else if (!strcasecmp(cmd, "threshold")) {
+  if (sscanf(line, "%lf%n", threshold, &n) != 1)
+return 0;
 } else {
   return 0;
 }
diff --git a/cmdparse.h b/cmdparse.h
index 095a8e2..3d6bbe0 100644
--- a/cmdparse.h
+++ b/cmdparse.h
@@ -47,7 +47,7 @@ extern int CPS_GetSelectOption(char *option);
 extern int CPS_ParseAllowDeny(char *line, int *all, IPAddr *ip, int 
*subnet_bits);
 
 /* Parse a command to enable local reference */
-extern int CPS_ParseLocal(char *line, int *stratum, int *orphan, double 
*distance);
+extern int CPS_ParseLocal(char *line, int *stratum, int *orphan, double 
*distance, double *threshold);
 
 /* Remove extra white-space and comments */
 extern void CPS_NormalizeLine(char *line);
diff --git a/conf.c b/conf.c
index 8849bdc..7af484b 100644
--- a/conf.c
+++ b/conf.c
@@ -129,6 +129,7 @@ static int enable_local=0;
 static int local_stratum;
 static int local_orphan;
 static double local_distance;
+static double local_threshold;
 
 /* Threshold (in seconds) - if absolute value of initial error is less
than this, slew instead of stepping */
@@ -1066,7 +1067,7 @@ parse_log(char *line)
 static void
 parse_local(char *line)
 {
-  if (!CPS_ParseLocal(line, &local_stratum, &loc

Re: [chrony-dev] [PATCH]

[Andy Fiddaman]

On Thu, 21 Mar 2024, Miroslav Lichvar wrote:

> I was going to respond to your pull request on github, I just had
> other things to do earlier.

I noticed that the github repo is marked as a mirror, and that most
discussion is on the mailing list so I switched to here. I am happy
to continue wherever is most convenient for you, and thank you for
replying.

> On Thu, Mar 21, 2024 at 12:18:02PM +, Andy Fiddaman wrote:
> > There is a bootstrapping problem, however. If the system comes up without
> > external connectivity, then the two boundary servers authoritatively
> > advertise 1986 at stratum 10. There are also several other scenarios we've
> > encountered that can occur depending on the state of connectivity.
> >
> > This patch adds two new options to "local" to help in these situations.
> >
> > The first, "local oncesynced" prevents the local reference being activated
> > unless time was synchronised at some point in the past.
>
> This makes sense to me, although I think it might be better to
> generalize it as an activating root distance, which would completement
> the distance option (threshold).

Oh, I like that idea. Shall I re-work the patch in those terms?
Any thoughts on a good name for the keyword?

> > The second, "local mintime" prevents the local reference being activated
> > unless the system clock is later than the specified time.
>
> Can you please explain why both options are needed? This seems more
> like a hack, that should have a better solution than making
> assumptions about absolute time.

This was the first thing I added, with the idea that we would set
the threshold to something that is before we ever shipped any
systems. With the other option, it is just belt and braces now
and not necessary. I can remove it along with the reworking above.

Andy


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH]

[Miroslav Lichvar]

I was going to respond to your pull request on github, I just had
other things to do earlier.

On Thu, Mar 21, 2024 at 12:18:02PM +, Andy Fiddaman wrote:
> There is a bootstrapping problem, however. If the system comes up without
> external connectivity, then the two boundary servers authoritatively
> advertise 1986 at stratum 10. There are also several other scenarios we've
> encountered that can occur depending on the state of connectivity.
> 
> This patch adds two new options to "local" to help in these situations.
> 
> The first, "local oncesynced" prevents the local reference being activated
> unless time was synchronised at some point in the past.

This makes sense to me, although I think it might be better to
generalize it as an activating root distance, which would completement
the distance option (threshold).

> The second, "local mintime" prevents the local reference being activated
> unless the system clock is later than the specified time.

Can you please explain why both options are needed? This seems more
like a hack, that should have a better solution than making
assumptions about absolute time.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH]

[Andy Fiddaman]

Hello,

I am working with a hierarchical deployment of chrony on a rack level
system which boots up with all of the clocks set to a time in 1986.

Two of the servers in the system have external connectivity and can
synchronise with external sources; we call these the "boundary"
servers. The rest of the servers are isolated, have no external
network connectivity, and can therefore only synchronise with the
boundary servers.

   +--+
   | External |
   |  Source  |
   +--+
 /  \
   /  \
 v  v
   +--++--+
   | Boundary || Boundary |
   |   NTP||   NTP|
   +--++--+
   ||| |||
   vvv vvv
 ++ ++++ ++
 |   NTP  | |   NTP  ||   NTP  | |   NTP  |
 ++ ++++ ++

For resilience against problems with the upstream sources or connectivity,
the boundary servers are configured with "local stratum 10".

There is a bootstrapping problem, however. If the system comes up without
external connectivity, then the two boundary servers authoritatively
advertise 1986 at stratum 10. There are also several other scenarios we've
encountered that can occur depending on the state of connectivity.

This patch adds two new options to "local" to help in these situations.

The first, "local oncesynced" prevents the local reference being activated
unless time was synchronised at some point in the past.

The second, "local mintime" prevents the local reference being activated
unless the system clock is later than the specified time.

Thanks for your consideration.

AndyFrom 31652b65a340492e78ce6c168c101fbd687c4e56 Mon Sep 17 00:00:00 2001
From: Andy Fiddaman 
Date: Tue, 19 Mar 2024 12:26:56 +
Subject: [PATCH] Add local "oncesyced" and "mintime" options

---
 candm.h  |  2 ++
 client.c | 10 --
 cmdmon.c | 10 +-
 cmdparse.c   | 13 -
 cmdparse.h   |  2 +-
 conf.c   |  9 +++--
 conf.h   |  2 +-
 doc/chrony.conf.adoc |  9 +
 reference.c  | 16 +---
 reference.h  |  2 +-
 10 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/candm.h b/candm.h
index 0894ad5..a173965 100644
--- a/candm.h
+++ b/candm.h
@@ -237,6 +237,8 @@ typedef struct {
   int32_t stratum;
   Float distance;
   int32_t orphan;
+  int32_t oncesynced;
+  Float mintime;
   int32_t EOR;
 } REQ_Local;
 
diff --git a/client.c b/client.c
index 0231b9e..ddc1a2c 100644
--- a/client.c
+++ b/client.c
@@ -754,12 +754,16 @@ process_cmd_burst(CMD_Request *msg, char *line)
 static int
 process_cmd_local(CMD_Request *msg, char *line)
 {
-  int on_off, stratum = 0, orphan = 0;
+  int on_off, stratum = 0, orphan = 0, oncesynced = 0;
   double distance = 0.0;
+  struct timespec mintime;
+
+  UTI_ZeroTimespec(&mintime);
 
   if (!strcmp(line, "off")) {
 on_off = 0;
-  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance)) {
+  } else if (CPS_ParseLocal(line, &stratum, &orphan, &distance,
+ &oncesynced, &mintime)) {
 on_off = 1;
   } else {
 LOG(LOGS_ERR, "Invalid syntax for local command");
@@ -771,6 +775,8 @@ process_cmd_local(CMD_Request *msg, char *line)
   msg->data.local.stratum = htonl(stratum);
   msg->data.local.distance = UTI_FloatHostToNetwork(distance);
   msg->data.local.orphan = htonl(orphan);
+  msg->data.local.oncesynced = htonl(oncesynced);
+  msg->data.local.mintime = 
UTI_FloatHostToNetwork(UTI_TimespecToDouble(&mintime));
 
   return 1;
 }
diff --git a/cmdmon.c b/cmdmon.c
index 716775f..c791517 100644
--- a/cmdmon.c
+++ b/cmdmon.c
@@ -529,9 +529,17 @@ static void
 handle_local(CMD_Request *rx_message, CMD_Reply *tx_message)
 {
   if (ntohl(rx_message->data.local.on_off)) {
+struct timespec mintime;
+double mintimeval;
+
+mintimeval = UTI_FloatNetworkToHost(rx_message->data.local.mintime),
+UTI_DoubleToTimespec(mintimeval, &mintime);
+
 REF_EnableLocal(ntohl(rx_message->data.local.stratum),
 UTI_FloatNetworkToHost(rx_message->data.local.distance),
-ntohl(rx_message->data.local.orphan));
+ntohl(rx_message->data.local.orphan),
+ntohl(rx_message->data.local.oncesynced),
+&mintime);
   } else {
 REF_DisableLocal();
   }
diff --git a/cmdparse.c b/cmdparse.c
index 0a80fc0..6e8ac99 100644
--- a/cmdparse.c
+++ b/cmdparse.c
@@ -296,14 +296,18 @@ CPS_ParseAllowDeny(char *line, int *all, IPAddr *ip, int 
*subnet_bits)
 /* == */
 
 int
-CPS_ParseLocal(char

[chrony-dev] [Git][chrony/chrony][master] 5 commits: test: replace another C99-style declaration in for loop

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
7fe98a83 by Miroslav Lichvar at 2024-03-11T12:00:12+01:00
test: replace another C99-style declaration in for loop

- - - - -
f49be7f0 by Miroslav Lichvar at 2024-03-12T14:57:30+01:00
conf: don't load sourcedir during initstepslew and RTC init

If the reload sources command was received in the chronyd start-up
sequence with initstepslew and/or RTC init (-s option), the sources
loaded from sourcedirs caused a crash due to failed assertion after
adding sources specified in the config.

Ignore the reload sources command until chronyd enters the normal
operation mode.

Fixes: 519796de3756 ("conf: add sourcedirs directive")

- - - - -
6d0143e9 by Miroslav Lichvar at 2024-03-14T16:39:32+01:00
ntp: add more debug messages for resolving

- - - - -
6e5513c8 by Miroslav Lichvar at 2024-03-14T16:39:41+01:00
ntp: don't keep refresh requests in list of unresolved sources

The refresh command adds requests to reresolve addresses of all sources.
If some sources didn't have an IP address resolved yet, the
corresponding requests were not removed after failed resolving. Repeated
refresh commands increased the number of requests and number of calls of
the system resolver, which might not be caching DNS responses.

Remove all refresh requests from the list after resolving attempt to fix
that.

Reported-by: t.barnew...@avm.de
Fixes: d7e3ad17ff7a ("ntp: create sources for unresolved addresses")

- - - - -
86386635 by Miroslav Lichvar at 2024-03-14T16:39:41+01:00
ntp: avoid unnecessary restart of resolving round on refresh

Don't call NSR_ResolveSources() when a resolving round is already
started. This cuts the number of calls of the system resolver made due
to the refresh command to half.

- - - - -


4 changed files:

- conf.c
- ntp_sources.c
- + test/simulation/203-initreload
- test/unit/leapdb.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/ad37c409c9170a5f4e2ee6068f49fcd0911b3215...863866354d058554e691959870770a8a07350431

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/ad37c409c9170a5f4e2ee6068f49fcd0911b3215...863866354d058554e691959870770a8a07350431
You're receiving this email because of your account on gitlab.com.

RE: [chrony-dev] timex kernel offset parameter not updated

[Filip Verwee]

Ok, thanks for the information.

Regards,
Filip Verwee.

-Original Message-
From: Miroslav Lichvar  
Sent: Tuesday, March 12, 2024 10:02 AM
To: chrony-dev@chrony.tuxfamily.org
Subject: Re: [chrony-dev] timex kernel offset parameter not updated

On Tue, Mar 12, 2024 at 08:35:43AM +, Filip Verwee wrote:
> Hi Miroslav,
> 
> Thanks for the reply.
> 
> Even if chronyd is not using the kernel PLL, wouldn't it be still possible to 
> update the offset parameter?

No, the offset can be set only when the PLL is enabled. In the kernel code 
(kernel/time/ntp.c):

static void ntp_update_offset(long offset) {
s64 freq_adj;
s64 offset64;
long secs;

if (!(time_status & STA_PLL))
return;

Even if it could be set and it did nothing except being reported back in timex, 
chronyd would need to update it periodically to be useful.
I don't think that would be acceptable as chronyd is supposed to be friendly to 
power saving.

--
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] timex kernel offset parameter not updated

[Miroslav Lichvar]

On Tue, Mar 12, 2024 at 08:35:43AM +, Filip Verwee wrote:
> Hi Miroslav,
> 
> Thanks for the reply.
> 
> Even if chronyd is not using the kernel PLL, wouldn't it be still possible to 
> update the offset parameter?

No, the offset can be set only when the PLL is enabled. In the
kernel code (kernel/time/ntp.c):

static void ntp_update_offset(long offset)
{
s64 freq_adj;
s64 offset64;
long secs;

if (!(time_status & STA_PLL))
return;

Even if it could be set and it did nothing except being reported back
in timex, chronyd would need to update it periodically to be useful.
I don't think that would be acceptable as chronyd is supposed to be
friendly to power saving.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

RE: [chrony-dev] timex kernel offset parameter not updated

[Filip Verwee]

Hi Miroslav,

Thanks for the reply.

Even if chronyd is not using the kernel PLL, wouldn't it be still possible to 
update the offset parameter?

Regards,
Filip Verwee.

-Original Message-
From: Miroslav Lichvar  
Sent: Tuesday, March 12, 2024 9:16 AM
To: chrony-dev@chrony.tuxfamily.org
Subject: Re: [chrony-dev] timex kernel offset parameter not updated

On Tue, Mar 12, 2024 at 08:04:04AM +, Filip Verwee wrote:
> Dear,
> 
> On our cluster nodes we use node-exporter to collect the timex information 
> from the kernel. The advantage of using the node-exporter timex collector is 
> that it is independent of the NTP implementation used on the nodes (ntpd, 
> chrony...). Unfortunately, it looks like chrony is not updating the timex 
> kernel offset parameter. Its value is always '0' while on nodes using ntpd, 
> the timex kernel offset parameter represents the time offset in between local 
> system and reference clock.
> This seems like a shortcoming in chrony. Are there any plans to implement 
> this functionality in the near future?

That is not possible as chronyd doesn't use the kernel PLL. The closest thing 
to the kernel PLL offset would be the chronyc tracking offset.

--
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] timex kernel offset parameter not updated

[Miroslav Lichvar]

On Tue, Mar 12, 2024 at 08:04:04AM +, Filip Verwee wrote:
> Dear,
> 
> On our cluster nodes we use node-exporter to collect the timex information 
> from the kernel. The advantage of using the node-exporter timex collector is 
> that it is independent of the NTP implementation used on the nodes (ntpd, 
> chrony...). Unfortunately, it looks like chrony is not updating the timex 
> kernel offset parameter. Its value is always '0' while on nodes using ntpd, 
> the timex kernel offset parameter represents the time offset in between local 
> system and reference clock.
> This seems like a shortcoming in chrony. Are there any plans to implement 
> this functionality in the near future?

That is not possible as chronyd doesn't use the kernel PLL. The
closest thing to the kernel PLL offset would be the chronyc tracking
offset.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] timex kernel offset parameter not updated

[Filip Verwee]

Dear,

On our cluster nodes we use node-exporter to collect the timex information from 
the kernel. The advantage of using the node-exporter timex collector is that it 
is independent of the NTP implementation used on the nodes (ntpd, chrony...). 
Unfortunately, it looks like chrony is not updating the timex kernel offset 
parameter. Its value is always '0' while on nodes using ntpd, the timex kernel 
offset parameter represents the time offset in between local system and 
reference clock.
This seems like a shortcoming in chrony. Are there any plans to implement this 
functionality in the near future?

Regards,
Filip Verwee.



This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, 
please notify the sender immediately and delete this message and any attachment 
from your system. Do not copy them or disclose the contents to any other person.

Re: [chrony-dev] [PATCH] Add support for the UT1 time scale

[Miroslav Lichvar]

On Wed, Mar 06, 2024 at 01:59:32PM +0300, Filipp Zapolskikh wrote:
> NTP servers running in the UT1 time scale are known (https://
> www.nist.gov/pml/time-and-frequency-division/time-services/
> ut1-ntp-time-dissemination). However, to access them, one needs to
> register in NIST and obtain an account, their software is unknown and
> is not open source, i.e. use is difficult, and deployment of new UT1
> NTP servers is impossible. I suggest filling this gap and trying to
> implement UT1 support in the open source project - chrony.

This probably wouldn't be a widely used feature. Are there any other
devices known to be using UT1 over NTP? NTPv5 should bring official
support for other timescales, but I wasn't planning to support UT1.

I'd prefer to reuse/share functionality with other use cases. I
already had a plan to add an offset command to chronyc to modify the
offset option of existing sources. This is now in git.

With that I think you can write a script that will periodically modify
the offset of all sources to follow the dUT1, i.e. keep the system
clock synchronized to UT1.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 2 commits: ntp+refclock: add functions to modify offset option

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
719c6f6a by Miroslav Lichvar at 2024-03-07T16:19:04+01:00
ntp+refclock: add functions to modify offset option

- - - - -
ad37c409 by Miroslav Lichvar at 2024-03-07T16:20:27+01:00
cmdmon: add offset command

Add a new command to modify the offset option of NTP sources and
reference clocks.

- - - - -


14 changed files:

- candm.h
- client.c
- cmdmon.c
- doc/chronyc.adoc
- ntp_core.c
- ntp_core.h
- ntp_sources.c
- ntp_sources.h
- pktlength.c
- refclock.c
- refclock.h
- stubs.c
- test/simulation/110-chronyc
- test/system/007-cmdmon


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/b0750136b50e674e329185925253207fa7c6b333...ad37c409c9170a5f4e2ee6068f49fcd0911b3215

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/b0750136b50e674e329185925253207fa7c6b333...ad37c409c9170a5f4e2ee6068f49fcd0911b3215
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] [PATCH] Add support for the UT1 time scale

[John Gilmore]

An interesting idea.  The documentation seems a little bit unclear
on just what this parameter changes.

Does it change the system clock of the system running it, into UT1?
Does it change the time reported to other NTP servers, reporting UT1?
Does it change the time expected from other NTP servers, accepting UT1?

Are these changes separate or are they tied together?  E.g. could
someone run a chrony daemon that serves UT1 clients, even though the
system time is in UTC?

If an ordinary NTP peer (that doesn't know about UT1) connects to a
chrony that's configured to report UT1, does that peer get confused
about the time, or is this error diagnosed?

Would two instances of chrony that peer, successfully diagnose that they
are running on different time scales?  On which end (or on both ends?)
is the UT1 scale configured?  Suppose this config is specified wrongly
at one end?

Thank you.

John

-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH] Add support for the UT1 time scale

[Filipp Zapolskikh]

CNF_HwTsInterface **iface);
 extern double CNF_GetHwTsTimeout(void);
 
@@ -174,4 +182,9 @@ extern int CNF_GetNtsTrustedCertsPaths(const char ***paths, 
uint32_t **ids);
 extern int CNF_GetNoSystemCert(void);
 extern int CNF_GetNoCertTimeCheck(void);
 
+extern int CNF_GetUT1(void);
+extern CNF_UT1_Source CNF_GetUT1Source(void);
+extern double CNF_GetUT1Offset(void);
+extern void CNF_SetUT1FromBulletinA(void *arg);
+
 #endif /* GOT_CONF_H */
diff --git a/doc/chrony.conf.adoc b/doc/chrony.conf.adoc
index bd296bc..179ca33 100644
--- a/doc/chrony.conf.adoc
+++ b/doc/chrony.conf.adoc
@@ -348,6 +348,8 @@ field should be enabled only for servers known to be 
running *chronyd* version
 These options force *chronyd* to use only IPv4 or IPv6 addresses respectively
 for this source. They do not override the *-4* or *-6* option on the *chronyd*
 command line.
+*ut1*:::
+This option specifies that the server operates in UT1 time scale. (NTP 
protocol itself has no information about the time scale and assumes usage of 
UTC). This allows to synchronise time correctly with both UTC and UT1 time 
sources.
 
 {blank}:::
 
@@ -1460,6 +1462,23 @@ where the _/etc/chrony.tempcomp_ file could have
 Valid measurements with corresponding compensations are logged to the
 _tempcomp.log_ file if enabled by the <> directive.
 
+[[ut1]]*ut1* _source_ _parameter_::
+The *ut1* directive sets the local time scale to UT1. It has two mandatory 
parameters: _dUT1_ value source and a source-specific parameter.
++
+UT1 differs from UTC by the variable offset _dUT1_ (in seconds) which is 
defined as
++
+
+dUT1 = UT1 - UTC
+
++
+So, _dUT1_ value is needed in order to determine UT1 time. This value will be 
obtained from the specified source. The following sources are available:
++
+*const*:::
+Constant value. The parameter is the actual value.
++
+*bulletina*:::
+Value is calculated from Bulletin A csv file using the linear interpolation. 
The parameter is the path to csv file.
+
 === NTP server
 
 [[allow]]*allow* [*all*] [_subnet_]::
diff --git a/ntp_core.c b/ntp_core.c
index 44682ec..eac1a0d 100644
--- a/ntp_core.c
+++ b/ntp_core.c
@@ -223,6 +223,9 @@ struct NCR_Instance_Record {
 
   /* Report from last valid response and packet/timestamp statistics */
   RPT_NTPReport report;
+
+  /* Flag indicating the source is in UT1 mode */
+  int ut1;
 };
 
 typedef struct {
@@ -711,6 +714,8 @@ NCR_CreateInstance(NTP_Remote_Address *remote_addr, 
NTP_Source_Type type,
   zero_local_timestamp(&result->local_tx);
   result->burst_good_samples_to_go = 0;
   result->burst_total_samples_to_go = 0;
+
+  result->ut1 = params->ut1;
   
   NCR_ResetInstance(result);
 
@@ -2180,6 +2185,9 @@ process_response(NCR_Instance inst, int saved, 
NTP_Local_Address *local_addr,
 /* Apply configured correction */
 sample.offset += inst->offset_correction;
 
+/* Apply dUT1 if the remote source works in another time scale */
+sample.offset += CNF_GetUT1Offset() * (CNF_GetUT1() - inst->ut1);
+
 /* We treat the time of the sample as being midway through the local
measurement period.  An analysis assuming constant relative
frequency and zero network delay shows this is the only possible
diff --git a/reference.c b/reference.c
index 1ac6cb9..f7ae5fb 100644
--- a/reference.c
+++ b/reference.c
@@ -252,6 +252,9 @@ REF_Initialise(void)
   leap_timeout_id = 0;
   leap_in_progress = 0;
   leap_mode = CNF_GetLeapSecMode();
+  /* Ignore leap second in UT1 mode */
+  if (CNF_GetUT1())
+leap_mode = REF_LeapModeIgnore;
   /* Switch to step mode if the system driver doesn't support leap */
   if (leap_mode == REF_LeapModeSystem && !LCL_CanSystemLeap())
 leap_mode = REF_LeapModeStep;
diff --git a/srcparams.h b/srcparams.h
index 31baed7..2abfb7a 100644
--- a/srcparams.h
+++ b/srcparams.h
@@ -65,6 +65,7 @@ typedef struct {
   double min_delay;
   double asymmetry;
   double offset;
+  int ut1;
 } SourceParameters;
 
 #define SRC_DEFAULT_PORT 123
-- 
2.44.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 2 commits: test: avoid C99-style declaration in for loop

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
ad79aec9 by Miroslav Lichvar at 2024-03-04T11:38:11+01:00
test: avoid C99-style declaration in for loop

This fixes compilation without the -std=c99 option with an older gcc.

- - - - -
b0750136 by Miroslav Lichvar at 2024-03-04T11:38:16+01:00
rtc+getdate: initialize tm_wday for mktime()

Even though mktime() is documented as ignoring the tm_wday field, the
coverity static analyzer complains about passing an uninitialized value.
Set the field to zero to make it happy.

- - - - -


3 changed files:

- getdate.y
- rtc_linux.c
- test/unit/leapdb.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/008dc16727dda8fedbb5b67bb83672e1c24565fc...b0750136b50e674e329185925253207fa7c6b333

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/008dc16727dda8fedbb5b67bb83672e1c24565fc...b0750136b50e674e329185925253207fa7c6b333
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] [PATCH v5 5/5] test/unit: add leapdb test

[Miroslav Lichvar]

On Mon, Feb 12, 2024 at 08:20:46AM +1100, Patrick Oppenlander wrote:
> Thanks for resolving those remaining issues. Looks like I should have
> been running a few more tests beyond "make check". How do you run the
> static analyser?

There is test/compilation/002-scanbuild in the repository to run
the clang static analyzer in few different chrony configurations.

I also run a Coverity scan we have access to at Red Hat before each
release. I think they provide a free service for open source projects,
but I'm not sure how that works.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v5 5/5] test/unit: add leapdb test

[Patrick Oppenlander]

On Fri, Feb 9, 2024 at 2:28 AM Miroslav Lichvar  wrote:
>
> On Thu, Feb 08, 2024 at 02:36:29PM +1100, patrick.oppenlan...@gmail.com wrote:
> > +} tests[] = {
> > +  /* leapdb.list is a cut down version of leap-seconds.list */
> > +  {3439756800, 34, LEAP_InsertSecond, 0}, /* 1 Jan 2009 */
> > +  {3550089600, 35, LEAP_InsertSecond, 0}, /* 1 Jul 2012 */
> > +  {3644697600, 36, LEAP_InsertSecond, 0}, /* 1 Jul 2015 */
> > +  {3692217600, 37, LEAP_InsertSecond, 0}, /* 1 Jan 2017 */
> > +  {34711891200, 36, LEAP_DeleteSecond, 1}, /* 1 Jan 3000 fake in 
> > leapdb.list */
>
> This value is too large to fit in 32-bit time_t. I changed it to 1 Jan
> 2020.

Ah, I didn't think of that as all of the platforms I work with are
64-bit time_t and have been for a few years now.

> There was also an issue I found after I updated the other tests. The
> refclock tai option checked only for leapsectz. And there was a new
> issue reported by static analyzer about uninitialized value, probably
> due to not being able to follow the new function pointers.

Thanks for resolving those remaining issues. Looks like I should have
been running a few more tests beyond "make check". How do you run the
static analyser?

Thanks for getting it merged,

Patrick

> Thanks,
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with 
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v5 5/5] test/unit: add leapdb test

[Miroslav Lichvar]

On Thu, Feb 08, 2024 at 02:36:29PM +1100, patrick.oppenlan...@gmail.com wrote:
> +} tests[] = {
> +  /* leapdb.list is a cut down version of leap-seconds.list */
> +  {3439756800, 34, LEAP_InsertSecond, 0}, /* 1 Jan 2009 */
> +  {3550089600, 35, LEAP_InsertSecond, 0}, /* 1 Jul 2012 */
> +  {3644697600, 36, LEAP_InsertSecond, 0}, /* 1 Jul 2015 */
> +  {3692217600, 37, LEAP_InsertSecond, 0}, /* 1 Jan 2017 */
> +  {34711891200, 36, LEAP_DeleteSecond, 1}, /* 1 Jan 3000 fake in leapdb.list 
> */

This value is too large to fit in 32-bit time_t. I changed it to 1 Jan
2020.

There was also an issue I found after I updated the other tests. The
refclock tai option checked only for leapsectz. And there was a new
issue reported by static analyzer about uninitialized value, probably
due to not being able to follow the new function pointers.

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [Git][chrony/chrony][master] 13 commits: ntp: support per-source IP family restriction

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
d7c2b1d2 by Miroslav Lichvar at 2024-02-07T10:23:36+01:00
ntp: support per-source IP family restriction

Add a new parameter to the NSR_AddSourceByName() function to allow
individual sources to be limited to IPv4 or IPv6 addresses. This doesn't
change the options passed to the resolver. It's just an additional
filter in the processing of resolved addresses following the -4/-6
command-line option of chronyd.

- - - - -
5cb584d6 by Miroslav Lichvar at 2024-02-07T10:23:40+01:00
conf: add ipv4 and ipv6 options to server/pool/peer directive

Accept "ipv4" and "ipv6" options in the server/pool/peer 
directive to
use only IPv4 or IPv6 addresses respectively.

The configuration is different from the "server [-4|-6] hostname" 
syntax
supported by ntpd to avoid breaking existing scripts which expect the
hostname to always be the first argument of the directives.

- - - - -
2d349595 by Miroslav Lichvar at 2024-02-07T10:23:40+01:00
cmdmon: simplify flag checking in handle_add_source()

- - - - -
637fa29e by Miroslav Lichvar at 2024-02-07T10:23:40+01:00
cmdmon: add ipv4/ipv6 options to add source command

- - - - -
8d19f493 by Miroslav Lichvar at 2024-02-07T10:23:40+01:00
ntp: add per-source counters of kernel and hardware timestamps

- - - - -
eb26d131 by Miroslav Lichvar at 2024-02-07T10:23:40+01:00
cmdmon: add timestamp counters to ntpdata report

- - - - -
017d6f8f by Patrick Oppenlander at 2024-02-08T12:54:37+01:00
reference: move leap second source into leapdb

Separate out source of leap second data into a new module in preparation
for supporting more sources such as leap-seconds.list.

- - - - -
02ae9a86 by Patrick Oppenlander at 2024-02-08T12:54:37+01:00
leapdb: make twice per day check logic common

We want to do the twice per day check regardless of the data source.
Move the check up one level from get_tz_leap() into LDB_GetLeap().

- - - - -
83f90279 by Patrick Oppenlander at 2024-02-08T15:54:21+01:00
leapdb: move source check into separate function

The sanity checks are valid for all possible sources of leap second
information, so move them into a separate function check_leap_source().

- - - - -
53823b9f by Patrick Oppenlander at 2024-02-08T15:54:24+01:00
leapdb: support leap-seconds.list as second source

The existing implementation of getting leap second information from a
timezone in get_tz_leap() relies on non-portable C library behaviour.

Specifically, mktime is not required to return '60' in the tm_sec field
when a leap second is inserted leading to "Timezone right/UTC failed
leap second check, ignoring" errors on musl based systems.

This patch adds support for getting leap second information from the
leap-seconds.list file included with tzdata and adds a new configuration
directive leapseclist to switch on the feature.

- - - - -
637b77d1 by Patrick Oppenlander at 2024-02-08T15:54:24+01:00
test: add leapdb unit test

- - - - -
6cf9fe2f by Miroslav Lichvar at 2024-02-08T15:54:24+01:00
test: improve 113-leapsecond and 124-tai tests

Use leapseclist instead of leapsectz and test also negative leap
seconds. Add a test for leapsectz when the date command indicates
right/UTC is available on the system and mktime() works as expected.
Check TAI offset in the server's log.

- - - - -
008dc167 by Miroslav Lichvar at 2024-02-08T16:21:42+01:00
examples: switch chrony.conf examples to leapseclist

- - - - -


30 changed files:

- Makefile.in
- candm.h
- client.c
- cmdmon.c
- cmdparse.c
- cmdparse.h
- conf.c
- conf.h
- doc/chrony.conf.adoc
- doc/chronyc.adoc
- examples/chrony.conf.example2
- examples/chrony.conf.example3
- + leapdb.c
- + leapdb.h
- main.c
- ntp_core.c
- ntp_sources.c
- ntp_sources.h
- pktlength.c
- refclock.c
- reference.c
- reports.h
- stubs.c
- test/simulation/110-chronyc
- test/simulation/113-leapsecond
- test/simulation/124-tai
- test/system/007-cmdmon
- + test/unit/leapdb.c
- + test/unit/leapdb.list
- test/unit/ntp_sources.c


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/e11b518a1ffa704986fb1f1835c425844ba248ef...008dc16727dda8fedbb5b67bb83672e1c24565fc

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/compare/e11b518a1ffa704986fb1f1835c425844ba248ef...008dc16727dda8fedbb5b67bb83672e1c24565fc
You're receiving this email because of your account on gitlab.com.

[chrony-dev] [PATCH v5 5/5] test/unit: add leapdb test

[patrick . oppenlander]

From: Patrick Oppenlander 

---
 test/unit/leapdb.c| 104 ++
 test/unit/leapdb.list |  22 +
 2 files changed, 126 insertions(+)
 create mode 100644 test/unit/leapdb.c
 create mode 100644 test/unit/leapdb.list

diff --git a/test/unit/leapdb.c b/test/unit/leapdb.c
new file mode 100644
index 000..b41278a
--- /dev/null
+++ b/test/unit/leapdb.c
@@ -0,0 +1,104 @@
+/*
+ **
+ * Copyright (C) Patrick Oppenlander 2023
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ **
+ */
+
+#include 
+#include "test.h"
+
+struct test_vector {
+  time_t when;
+  int tai_offset;
+  NTP_Leap leap;
+  int fake;
+} tests[] = {
+  /* leapdb.list is a cut down version of leap-seconds.list */
+  {3439756800, 34, LEAP_InsertSecond, 0}, /* 1 Jan 2009 */
+  {3550089600, 35, LEAP_InsertSecond, 0}, /* 1 Jul 2012 */
+  {3644697600, 36, LEAP_InsertSecond, 0}, /* 1 Jul 2015 */
+  {3692217600, 37, LEAP_InsertSecond, 0}, /* 1 Jan 2017 */
+  {34711891200, 36, LEAP_DeleteSecond, 1}, /* 1 Jan 3000 fake in leapdb.list */
+};
+
+static void
+test_leap_source(NTP_Leap (*fn)(time_t when, int *tai_offset),
+ int skip_fakes)
+{
+  int prev_tai_offset = 34;
+  for (int i = 0; i < sizeof tests / sizeof tests[0]; ++i) {
+struct test_vector *t = tests + i;
+
+NTP_Leap leap;
+int tai_offset = -1;
+
+/* Our unit test leapdb.list contains a fake entry removing a leap second.
+ * Skip this when testing with the right/UTC timezone using mktime(). */
+if (skip_fakes && t->fake)
+  continue;
+
+/* One second before leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET - 1, &tai_offset);
+TEST_CHECK(leap == t->leap);
+TEST_CHECK(tai_offset = prev_tai_offset);
+
+/* Exactly on leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+/* One second after leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET + 1, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+prev_tai_offset = t->tai_offset;
+  }
+}
+
+void
+test_unit(void)
+{
+  char conf[][100] = {
+"leapsectz right/UTC",
+"leapseclist leapdb.list"
+  };
+
+  CNF_Initialise(0, 0);
+  for (int i = 0; i < sizeof conf / sizeof conf[0]; i++)
+CNF_ParseLine(NULL, i + 1, conf[i]);
+  LDB_Initialise();
+
+  if (check_leap_source(get_tz_leap)) {
+DEBUG_LOG("testing get_tz_leap");
+test_leap_source(get_tz_leap, 1);
+  } else {
+DEBUG_LOG("Skipping get_tz_leap test. Either the right/UTC timezone is "
+ "missing, or mktime() doesn't support leap seconds.");
+  }
+
+  DEBUG_LOG("testing get_list_leap");
+  TEST_CHECK(check_leap_source(get_list_leap));
+  test_leap_source(get_list_leap, 0);
+
+  /* This exercises the twice-per-day logic */
+  DEBUG_LOG("testing LDB_GetLeap");
+  test_leap_source(LDB_GetLeap, 1);
+
+  LDB_Finalise();
+  CNF_Finalise();
+}
diff --git a/test/unit/leapdb.list b/test/unit/leapdb.list
new file mode 100644
index 000..8fd2ae9
--- /dev/null
+++ b/test/unit/leapdb.list
@@ -0,0 +1,22 @@
+#
+# Cut down version of leap-seconds.list for unit test.
+#
+# Blank lines need to be ignored, so include a few for testing.
+# Whitespace errors on non-blank lines below are copied from the original file.
+#
+   
+#  Leap second data update time
+#$  3676924800
+#
+#  File update time
+#@ 3928521600
+ 
+3439756800 34  # 1 Jan 2009
+3550089600 35  # 1 Jul 2012
+3644697600 36  # 1 Jul 2015
+3692217600 37  # 1 Jan 2017
+3471189120036  # 1 Jan 3000 (fake entry to test negative leap second)
+
+#  FIPS 180-1 hash
+#  NOTE! this value has not been recomputed for this unit test file.
+#h 16edd0f0 3666784f 37db6bdd e74ced87 59af48f1
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v5 4/5] leapdb: support leap-seconds.list as second source

[patrick . oppenlander]

taining leap seconds occuring at midnight */
-static char *leap_tzname;
+/* Source of leap second data */
+enum {
+  SRC_NONE,
+  SRC_TIMEZONE,
+  SRC_LIST,
+} leap_src;
+
+/* Offset between leap-seconds.list timestamp epoch and Unix epoch.
+   leap-seconds.list epoch is 1 Jan 1900, 00:00:00 */
+#define LEAP_SEC_LIST_OFFSET 2208988800
 
 /* == */
 
@@ -59,7 +69,7 @@ get_tz_leap(time_t when, int *tai_offset)
   return tz_leap;
 strcpy(tz_orig, tz_env);
   }
-  setenv("TZ", leap_tzname, 1);
+  setenv("TZ", CNF_GetLeapSecTimezone(), 1);
   tzset();
 
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
@@ -93,6 +103,89 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
+static NTP_Leap
+get_list_leap(time_t when, int *tai_offset)
+{
+  FILE *f;
+  char line[1024];
+  NTP_Leap ret_leap = LEAP_Normal;
+  int ret_tai_offset = 0, prev_lsl_tai_offset = 10;
+  int64_t lsl_updated = 0, lsl_expiry = 0;
+  const char *leap_sec_list = CNF_GetLeapSecList();
+
+  if (!(f = UTI_OpenFile(NULL, leap_sec_list, NULL, 'r', 0))) {
+LOG(LOGS_ERR, "Failed to open leap seconds list %s", leap_sec_list);
+goto out;
+  }
+
+  /* Leap second happens at midnight */
+  when = (when / (24 * 3600) + 1) * (24 * 3600);
+
+  /* leap-seconds.list timestamps are relative to 1 Jan 1900, 00:00:00 */
+  when += LEAP_SEC_LIST_OFFSET;
+
+  while (fgets(line, sizeof line, f) > 0) {
+int64_t lsl_when;
+int lsl_tai_offset;
+char *p;
+
+/* Ignore blank lines */
+for (p = line; *p && isspace(*p); ++p);
+if (!*p)
+  continue;
+
+if (*line == '#') {
+  /* Update time line starts with #$ */
+  if (line[1] == '$' && sscanf(line + 2, "%"SCNd64, &lsl_updated) != 1)
+goto error;
+  /* Expiration time line starts with #@ */
+  if (line[1] == '@' && sscanf(line + 2, "%"SCNd64, &lsl_expiry) != 1)
+goto error;
+  /* Comment or a special comment we don't care about */
+  continue;
+}
+
+/* Leap entry */
+if (sscanf(line, "%"SCNd64" %d", &lsl_when, &lsl_tai_offset) != 2)
+  goto error;
+
+if (when == lsl_when) {
+  if (lsl_tai_offset > prev_lsl_tai_offset)
+ret_leap = LEAP_InsertSecond;
+  else if (lsl_tai_offset < prev_lsl_tai_offset)
+ret_leap = LEAP_DeleteSecond;
+  /* When is rounded to the end of the day, so offset hasn't changed yet! 
*/
+  ret_tai_offset = prev_lsl_tai_offset;
+} else if (when > lsl_when)
+  ret_tai_offset = lsl_tai_offset;
+
+prev_lsl_tai_offset = lsl_tai_offset;
+  }
+
+  /* Make sure the file looks sensible */
+  if (!feof(f) || !lsl_updated || !lsl_expiry)
+goto error;
+
+  if (when >= lsl_expiry)
+LOG(LOGS_WARN, "Leap second list %s needs update", leap_sec_list);
+
+  goto out;
+
+error:
+  if (f)
+fclose(f);
+  LOG(LOGS_ERR, "Failed to parse leap seconds list %s", leap_sec_list);
+  return LEAP_Normal;
+
+out:
+  if (f)
+fclose(f);
+  *tai_offset = ret_tai_offset;
+  return ret_leap;
+}
+
+/* == */
+
 static int
 check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
@@ -111,14 +204,27 @@ check_leap_source(NTP_Leap (*src)(time_t when, int 
*tai_offset))
 void
 LDB_Initialise(void)
 {
+  const char *leap_tzname, *leap_sec_list;
+
   leap_tzname = CNF_GetLeapSecTimezone();
   if (leap_tzname && !check_leap_source(get_tz_leap)) {
 LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
 leap_tzname = NULL;
   }
 
-  if (leap_tzname)
+  leap_sec_list = CNF_GetLeapSecList();
+  if (leap_sec_list && !check_leap_source(get_list_leap)) {
+LOG(LOGS_WARN, "Leap second list %s failed check, ignoring", 
leap_sec_list);
+leap_sec_list = NULL;
+  }
+
+  if (leap_sec_list) {
+LOG(LOGS_INFO, "Using leap second list %s", leap_sec_list);
+leap_src = SRC_LIST;
+  } else if (leap_tzname) {
 LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
+leap_src = SRC_TIMEZONE;
+  }
 }
 
 /* == */
@@ -139,8 +245,16 @@ LDB_GetLeap(time_t when, int *tai_offset)
   ldb_leap = LEAP_Normal;
   ldb_tai_offset = 0;
 
-  if (leap_tzname)
+  switch (leap_src) {
+  case SRC_NONE:
+break;
+  case SRC_TIMEZONE:
 ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+break;
+  case SRC_LIST:
+ldb_leap = get_list_leap(when, &ldb_tai_offset);
+break;
+  }
 
 out:
   *tai_offset = ldb_tai_offset;
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v5 3/5] leapdb: move source check into separate function

[patrick . oppenlander]

From: Patrick Oppenlander 

The sanity checks are valid for all possible sources of leap second
information, so move them into a separate function check_leap_source().
---
 leapdb.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 32f753a..c8a42cb 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -93,22 +93,32 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
-void
-LDB_Initialise(void)
+static int
+check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
   int tai_offset;
 
+  /* Check that the leap second source has good data for Jun 30 2012 and Dec 
31 2012 */
+  if (src(1341014400, &tai_offset) == LEAP_InsertSecond && tai_offset == 34 &&
+  src(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 35)
+return 1;
+
+  return 0;
+}
+
+/* == */
+
+void
+LDB_Initialise(void)
+{
   leap_tzname = CNF_GetLeapSecTimezone();
-  if (leap_tzname) {
-/* Check that the timezone has good data for Jun 30 2012 and Dec 31 2012 */
-if (get_tz_leap(1341014400, &tai_offset) == LEAP_InsertSecond && 
tai_offset == 34 &&
-get_tz_leap(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 
35) {
-  LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
-} else {
-  LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
-  leap_tzname = NULL;
-}
+  if (leap_tzname && !check_leap_source(get_tz_leap)) {
+LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
+leap_tzname = NULL;
   }
+
+  if (leap_tzname)
+LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v5 1/5] reference: move leap second source into leapdb

[patrick . oppenlander]

offset = 0;
-
-  tm = gmtime(&when);
-  if (!tm)
-return tz_leap;
-
-  stm = *tm;
-
-  /* Temporarily switch to the timezone containing leap seconds */
-  tz_env = getenv("TZ");
-  if (tz_env) {
-if (strlen(tz_env) >= sizeof (tz_orig))
-  return tz_leap;
-strcpy(tz_orig, tz_env);
-  }
-  setenv("TZ", leap_tzname, 1);
-  tzset();
-
-  /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
-  t = mktime(&stm);
-  if (t != -1)
-tz_tai_offset = t - when + 10;
-
-  /* Set the time to 23:59:60 and see how it overflows in mktime() */
-  stm.tm_sec = 60;
-  stm.tm_min = 59;
-  stm.tm_hour = 23;
-
-  t = mktime(&stm);
-
-  if (tz_env)
-setenv("TZ", tz_orig, 1);
-  else
-unsetenv("TZ");
-  tzset();
-
-  if (t == -1)
-return tz_leap;
-
-  if (stm.tm_sec == 60)
-tz_leap = LEAP_InsertSecond;
-  else if (stm.tm_sec == 1)
-tz_leap = LEAP_DeleteSecond;
-
-  *tai_offset = tz_tai_offset;
-
-  return tz_leap;
-}
-
-/* == */
-
 static void
 leap_end_timeout(void *arg)
 {
@@ -751,16 +664,16 @@ set_leap_timeout(time_t now)
 static void
 update_leap_status(NTP_Leap leap, time_t now, int reset)
 {
-  NTP_Leap tz_leap;
+  NTP_Leap ldb_leap;
   int leap_sec, tai_offset;
 
   leap_sec = 0;
   tai_offset = 0;
 
-  if (leap_tzname && now) {
-tz_leap = get_tz_leap(now, &tai_offset);
+  if (now) {
+ldb_leap = LDB_GetLeap(now, &tai_offset);
 if (leap == LEAP_Normal)
-  leap = tz_leap;
+  leap = ldb_leap;
   }
 
   if (leap == LEAP_InsertSecond || leap == LEAP_DeleteSecond) {
@@ -1398,7 +1311,7 @@ REF_GetTaiOffset(struct timespec *ts)
 {
   int tai_offset;
 
-  get_tz_leap(ts->tv_sec, &tai_offset);
+  LDB_GetLeap(ts->tv_sec, &tai_offset);
 
   return tai_offset;
 }
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v5 2/5] leapdb: make twice per day check logic common

[patrick . oppenlander]

From: Patrick Oppenlander 

We want to do the twice per day check regardless of the data source.
Move the check up one level from get_tz_leap() into LDB_GetLeap().
---
 leapdb.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 676a0d5..32f753a 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -41,24 +41,10 @@ static char *leap_tzname;
 static NTP_Leap
 get_tz_leap(time_t when, int *tai_offset)
 {
-  static time_t last_tz_leap_check;
-  static NTP_Leap tz_leap;
-  static int tz_tai_offset;
-
   struct tm stm, *tm;
   time_t t;
   char *tz_env, tz_orig[128];
-
-  *tai_offset = tz_tai_offset;
-
-  /* Do this check at most twice a day */
-  when = when / (12 * 3600) * (12 * 3600);
-  if (last_tz_leap_check == when)
-  return tz_leap;
-
-  last_tz_leap_check = when;
-  tz_leap = LEAP_Normal;
-  tz_tai_offset = 0;
+  NTP_Leap tz_leap = LEAP_Normal;
 
   tm = gmtime(&when);
   if (!tm)
@@ -79,7 +65,7 @@ get_tz_leap(time_t when, int *tai_offset)
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
   t = mktime(&stm);
   if (t != -1)
-tz_tai_offset = t - when + 10;
+*tai_offset = t - when + 10;
 
   /* Set the time to 23:59:60 and see how it overflows in mktime() */
   stm.tm_sec = 60;
@@ -102,8 +88,6 @@ get_tz_leap(time_t when, int *tai_offset)
   else if (stm.tm_sec == 1)
 tz_leap = LEAP_DeleteSecond;
 
-  *tai_offset = tz_tai_offset;
-
   return tz_leap;
 }
 
@@ -132,10 +116,25 @@ LDB_Initialise(void)
 NTP_Leap
 LDB_GetLeap(time_t when, int *tai_offset)
 {
-  *tai_offset = 0;
+  static time_t last_ldb_leap_check;
+  static NTP_Leap ldb_leap;
+  static int ldb_tai_offset;
+
+  /* Do this check at most twice a day */
+  when = when / (12 * 3600) * (12 * 3600);
+  if (last_ldb_leap_check == when)
+goto out;
+
+  last_ldb_leap_check = when;
+  ldb_leap = LEAP_Normal;
+  ldb_tai_offset = 0;
+
   if (leap_tzname)
-return get_tz_leap(when, tai_offset);
-  return LEAP_Normal;
+ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+
+out:
+  *tai_offset = ldb_tai_offset;
+  return ldb_leap;
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v5 0/5] support leap-seconds.list

[patrick . oppenlander]

From: Patrick Oppenlander 

Hi Miroslav,

thanks for the feedback. Here's an updated series.

Changes from v4:
* Fix test on systems where mktime() doesn't support leap seconds or where the
  right/UTC timezone is not installed.
* Add a test with a negative leap second.
* Newer leap-second.list doesn't wrap at 80 chars, make the line buffer bigger.
* Fix error path in get_list_leap so that if leap-seconds.list fails to parse
  we don't return new values.

Changes from v3:
* Include cut down leap second database for unit test.
* Add a comment about leap-seconds.list format to chrony.conf.adoc.
* Use UTI_OpenFile() instead of fopen(), fgets() instead of getline().
* Fix handling of blank lines while parsing leap-seconds.list.
* Comment fixes, function & enumerator naming and other minor cleanups.

Changes from v2:
* Fix copyright notices.
* Rework to avoid storing leap-seconds.list in memory, parse on the fly.
* Minimise function pointer use.
* Comment fixes, include ordering, naming and other minor cleanups.

Changes from v1:
* Add a new leapdb module with unit test.
* Make 12 hour caching logic common.
* Make sanity checking logic common.
* Don't cache leap-seconds.list contents between calls.
* Naming and other minor cleanups.

Thanks,



Patrick Oppenlander (5):
  reference: move leap second source into leapdb
  leapdb: make twice per day check logic common
  leapdb: move source check into separate function
  leapdb: support leap-seconds.list as second source
  test/unit: add leapdb test

 Makefile.in   |   2 +-
 conf.c|  14 +++
 conf.h|   1 +
 doc/chrony.conf.adoc  |  20 +++-
 leapdb.c  | 270 ++
 leapdb.h  |  37 ++
 main.c|   3 +
 reference.c   |  99 +---
 test/unit/leapdb.c| 104 
 test/unit/leapdb.list |  22 
 10 files changed, 475 insertions(+), 97 deletions(-)
 create mode 100644 leapdb.c
 create mode 100644 leapdb.h
 create mode 100644 test/unit/leapdb.c
 create mode 100644 test/unit/leapdb.list

-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v4 4/5] leapdb: support leap-seconds.list as second source

[Patrick Oppenlander]

On Wed, Feb 7, 2024 at 9:35 PM Miroslav Lichvar  wrote:
>
> On Wed, Feb 07, 2024 at 04:29:43PM +1100, patrick.oppenlan...@gmail.com wrote:
> > +  while (fgets(line, sizeof line, f) > 0) {
> > +int64_t lsl_when;
> > +int lsl_tai_offset;
> > +char *p;
> > +
> > +/* Ignore blank lines */
> > +for (p = line; *p && isspace(*p); ++p);
> > +if (!*p)
> > +  continue;
> > +
> > +if (*line == '#') {
> > +  /* Update time line starts with #$ */
> > +  if (line[1] == '$' && sscanf(line + 2, "%"SCNd64, &lsl_updated) != 1)
> > +goto error;
> > +  /* Expiration time line starts with #@ */
> > +  if (line[1] == '@' && sscanf(line + 2, "%"SCNd64, &lsl_expiry) != 1)
> > +goto error;
> > +  /* Comment or a special comment we don't care about */
> > +  continue;
> > +}
> > +
> > +/* Leap entry */
> > +if (sscanf(line, "%"SCNd64" %d", &lsl_when, &lsl_tai_offset) != 2)
> > +  goto error;
> > +
> > +if (when == lsl_when) {
> > +  if (lsl_tai_offset > prev_lsl_tai_offset)
> > +lsl_leap = LEAP_InsertSecond;
> > +  else if (lsl_tai_offset < prev_lsl_tai_offset)
> > +lsl_leap = LEAP_DeleteSecond;
> > +  /* When is rounded to the end of the day, so offset hasn't changed 
> > yet! */
> > +  *tai_offset = prev_lsl_tai_offset;
> > +} else if (when > lsl_when)
> > +  *tai_offset = lsl_tai_offset;
> > +
> > +prev_lsl_tai_offset = lsl_tai_offset;
> > +  }
> > +
> > +  /* Make sure the file looks sensible */
> > +  if (!feof(f) || !lsl_updated || !lsl_expiry)
> > +goto error;
>
> The error path taken here and in the loop logs an error message, but
> the leap and TAI offset values can already be accepted at that point.
> I think either they should be saved to temporary variables, or the
> loop should stop when a matching entry is found, so the error message
> is not logged when the result is used.

Thanks for pointing that out. I'll go with temporary variables. I
think it's better not to use the values if the file looks bogus.

> Everything else looks good to me. Thanks for your work on this.

Thanks for spending the time to review it,

Patrick

> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with 
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v4 5/5] test/unit: add leapdb test

[Patrick Oppenlander]

On Wed, Feb 7, 2024 at 9:19 PM Miroslav Lichvar  wrote:
>
> On Wed, Feb 07, 2024 at 04:29:44PM +1100, patrick.oppenlan...@gmail.com wrote:
> > +void
> > +test_unit(void)
> > +{
> > +  char conf[][100] = {
> > +"leapsectz right/UTC",
> > +"leapseclist leapdb.list"
> > +  };
> > +
> > +  CNF_Initialise(0, 0);
> > +  for (int i = 0; i < sizeof conf / sizeof conf[0]; i++)
> > +CNF_ParseLine(NULL, i + 1, conf[i]);
> > +  LDB_Initialise();
> > +
> > +  DEBUG_LOG("testing get_tz_leap");
> > +  test_leap_source(get_tz_leap);
>
> This still seems to fail on a system which doesn't have the right/UTC
> timezone, or where mktime() doesn't do the expected thing. Unit tests
> need to pass on all supported systems. If there is no simple solution,
> I think not testing get_tz_leap here would be acceptable. The
> functionality is already covered in the 113-leapsecond test.

Oops, I overlooked this. Will propose a fix.

> > +# Blank lines need to be ignored, so include a few for testing.
> > +# Whitespace errors on non-blank lines below are copied from the original 
> > file.
> > +#
> > +
> > +#Leap second data update time
> > +#$3676924800
> > +#
> > +#File update time
> > +#@   3928521600
> > +
>
> The white space in the blank line above is intentional?

leap-seconds.list says "A blank line should be ignored", but doesn't
specify what blank is. I intentionally added some whitespace errors on
a couple of blank lines to make sure we correctly skip them. I can
clean them up if you would prefer not to test this?

Interestingly, the comment block in leap-seconds.list is completely
different between the 2023d-1 and 2024a-1 packages on Arch. Only the
older one mentions blank lines.

> > +3439756800   34  # 1 Jan 2009
> > +3550089600   35  # 1 Jul 2012
> > +3644697600   36  # 1 Jul 2015
> > +3692217600   37  # 1 Jan 2017
>
> How about adding and testing a negative leap second?

Will do.

Patrick

> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with 
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v4 4/5] leapdb: support leap-seconds.list as second source

[Miroslav Lichvar]

On Wed, Feb 07, 2024 at 04:29:43PM +1100, patrick.oppenlan...@gmail.com wrote:
> +  while (fgets(line, sizeof line, f) > 0) {
> +int64_t lsl_when;
> +int lsl_tai_offset;
> +char *p;
> +
> +/* Ignore blank lines */
> +for (p = line; *p && isspace(*p); ++p);
> +if (!*p)
> +  continue;
> +
> +if (*line == '#') {
> +  /* Update time line starts with #$ */
> +  if (line[1] == '$' && sscanf(line + 2, "%"SCNd64, &lsl_updated) != 1)
> +goto error;
> +  /* Expiration time line starts with #@ */
> +  if (line[1] == '@' && sscanf(line + 2, "%"SCNd64, &lsl_expiry) != 1)
> +goto error;
> +  /* Comment or a special comment we don't care about */
> +  continue;
> +}
> +
> +/* Leap entry */
> +if (sscanf(line, "%"SCNd64" %d", &lsl_when, &lsl_tai_offset) != 2)
> +  goto error;
> +
> +if (when == lsl_when) {
> +  if (lsl_tai_offset > prev_lsl_tai_offset)
> +lsl_leap = LEAP_InsertSecond;
> +  else if (lsl_tai_offset < prev_lsl_tai_offset)
> +lsl_leap = LEAP_DeleteSecond;
> +  /* When is rounded to the end of the day, so offset hasn't changed 
> yet! */
> +  *tai_offset = prev_lsl_tai_offset;
> +} else if (when > lsl_when)
> +  *tai_offset = lsl_tai_offset;
> +
> +prev_lsl_tai_offset = lsl_tai_offset;
> +  }
> +
> +  /* Make sure the file looks sensible */
> +  if (!feof(f) || !lsl_updated || !lsl_expiry)
> +goto error;

The error path taken here and in the loop logs an error message, but
the leap and TAI offset values can already be accepted at that point.
I think either they should be saved to temporary variables, or the
loop should stop when a matching entry is found, so the error message
is not logged when the result is used.

Everything else looks good to me. Thanks for your work on this.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v4 5/5] test/unit: add leapdb test

[Miroslav Lichvar]

On Wed, Feb 07, 2024 at 04:29:44PM +1100, patrick.oppenlan...@gmail.com wrote:
> +void
> +test_unit(void)
> +{
> +  char conf[][100] = {
> +"leapsectz right/UTC",
> +"leapseclist leapdb.list"
> +  };
> +
> +  CNF_Initialise(0, 0);
> +  for (int i = 0; i < sizeof conf / sizeof conf[0]; i++)
> +CNF_ParseLine(NULL, i + 1, conf[i]);
> +  LDB_Initialise();
> +
> +  DEBUG_LOG("testing get_tz_leap");
> +  test_leap_source(get_tz_leap);

This still seems to fail on a system which doesn't have the right/UTC
timezone, or where mktime() doesn't do the expected thing. Unit tests
need to pass on all supported systems. If there is no simple solution,
I think not testing get_tz_leap here would be acceptable. The
functionality is already covered in the 113-leapsecond test.

> +# Blank lines need to be ignored, so include a few for testing.
> +# Whitespace errors on non-blank lines below are copied from the original 
> file.
> +#
> + 
> +#Leap second data update time
> +#$3676924800
> +#
> +#File update time
> +#@   3928521600
> +   

The white space in the blank line above is intentional?

> +3439756800   34  # 1 Jan 2009
> +3550089600   35  # 1 Jul 2012
> +3644697600   36  # 1 Jul 2015
> +3692217600   37  # 1 Jan 2017

How about adding and testing a negative leap second?

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 5/5] test/unit: add leapdb test

[patrick . oppenlander]

From: Patrick Oppenlander 

---
 test/unit/leapdb.c| 92 +++
 test/unit/leapdb.list | 21 ++
 2 files changed, 113 insertions(+)
 create mode 100644 test/unit/leapdb.c
 create mode 100644 test/unit/leapdb.list

diff --git a/test/unit/leapdb.c b/test/unit/leapdb.c
new file mode 100644
index 000..f3fcaf2
--- /dev/null
+++ b/test/unit/leapdb.c
@@ -0,0 +1,92 @@
+/*
+ **
+ * Copyright (C) Patrick Oppenlander 2023
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ **
+ */
+
+#include 
+#include "test.h"
+
+struct test_vector {
+  time_t when;
+  int tai_offset;
+  NTP_Leap leap;
+} tests[] = {
+  /* leapdb_test.list is a cut down version of leap-seconds.list */
+  {3439756800, 34, LEAP_InsertSecond}, /* 1 Jan 2009 */
+  {3550089600, 35, LEAP_InsertSecond}, /* 1 Jul 2012 */
+  {3644697600, 36, LEAP_InsertSecond}, /* 1 Jul 2015 */
+  {3692217600, 37, LEAP_InsertSecond}, /* 1 Jan 2017 */
+};
+
+static void
+test_leap_source(NTP_Leap (*fn)(time_t when, int *tai_offset))
+{
+  TEST_CHECK(check_leap_source(fn));
+
+  int prev_tai_offset = 34;
+  for (int i = 0; i < sizeof tests / sizeof tests[0]; ++i) {
+struct test_vector *t = tests + i;
+
+NTP_Leap leap;
+int tai_offset = -1;
+
+/* One second before leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET - 1, &tai_offset);
+TEST_CHECK(leap == t->leap);
+TEST_CHECK(tai_offset = prev_tai_offset);
+
+/* Exactly on leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+/* One second after leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET + 1, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+prev_tai_offset = t->tai_offset;
+  }
+}
+
+void
+test_unit(void)
+{
+  char conf[][100] = {
+"leapsectz right/UTC",
+"leapseclist leapdb.list"
+  };
+
+  CNF_Initialise(0, 0);
+  for (int i = 0; i < sizeof conf / sizeof conf[0]; i++)
+CNF_ParseLine(NULL, i + 1, conf[i]);
+  LDB_Initialise();
+
+  DEBUG_LOG("testing get_tz_leap");
+  test_leap_source(get_tz_leap);
+
+  DEBUG_LOG("testing get_list_leap");
+  test_leap_source(get_list_leap);
+
+  /* This exercises the twice-per-day logic */
+  DEBUG_LOG("testing LDB_GetLeap");
+  test_leap_source(LDB_GetLeap);
+
+  LDB_Finalise();
+  CNF_Finalise();
+}
diff --git a/test/unit/leapdb.list b/test/unit/leapdb.list
new file mode 100644
index 000..861a426
--- /dev/null
+++ b/test/unit/leapdb.list
@@ -0,0 +1,21 @@
+#
+# Cut down version of leap-seconds.list for unit test.
+#
+# Blank lines need to be ignored, so include a few for testing.
+# Whitespace errors on non-blank lines below are copied from the original file.
+#
+   
+#  Leap second data update time
+#$  3676924800
+#
+#  File update time
+#@ 3928521600
+ 
+3439756800 34  # 1 Jan 2009
+3550089600 35  # 1 Jul 2012
+3644697600 36  # 1 Jul 2015
+3692217600 37  # 1 Jan 2017
+
+#  FIPS 180-1 hash
+#  NOTE! this value has not been recomputed for this unit test file.
+#h 16edd0f0 3666784f 37db6bdd e74ced87 59af48f1
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 4/5] leapdb: support leap-seconds.list as second source

[patrick . oppenlander]

taining leap seconds occuring at midnight */
-static char *leap_tzname;
+/* Source of leap second data */
+enum {
+  SRC_NONE,
+  SRC_TIMEZONE,
+  SRC_LIST,
+} leap_src;
+
+/* Offset between leap-seconds.list timestamp epoch and Unix epoch.
+   leap-seconds.list epoch is 1 Jan 1900, 00:00:00 */
+#define LEAP_SEC_LIST_OFFSET 2208988800
 
 /* == */
 
@@ -59,7 +69,7 @@ get_tz_leap(time_t when, int *tai_offset)
   return tz_leap;
 strcpy(tz_orig, tz_env);
   }
-  setenv("TZ", leap_tzname, 1);
+  setenv("TZ", CNF_GetLeapSecTimezone(), 1);
   tzset();
 
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
@@ -93,6 +103,84 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
+static NTP_Leap
+get_list_leap(time_t when, int *tai_offset)
+{
+  FILE *f;
+  char line[96]; /* leap-seconds.list wraps at 80 chars */
+  NTP_Leap lsl_leap = LEAP_Normal;
+  int prev_lsl_tai_offset = 10;
+  int64_t lsl_updated = 0, lsl_expiry = 0;
+  const char *leap_sec_list = CNF_GetLeapSecList();
+
+  if (!(f = UTI_OpenFile(NULL, leap_sec_list, NULL, 'r', 0))) {
+LOG(LOGS_ERR, "Failed to open leap seconds list %s", leap_sec_list);
+goto out;
+  }
+
+  /* Leap second happens at midnight */
+  when = (when / (24 * 3600) + 1) * (24 * 3600);
+
+  /* leap-seconds.list timestamps are relative to 1 Jan 1900, 00:00:00 */
+  when += LEAP_SEC_LIST_OFFSET;
+
+  while (fgets(line, sizeof line, f) > 0) {
+int64_t lsl_when;
+int lsl_tai_offset;
+char *p;
+
+/* Ignore blank lines */
+for (p = line; *p && isspace(*p); ++p);
+if (!*p)
+  continue;
+
+if (*line == '#') {
+  /* Update time line starts with #$ */
+  if (line[1] == '$' && sscanf(line + 2, "%"SCNd64, &lsl_updated) != 1)
+goto error;
+  /* Expiration time line starts with #@ */
+  if (line[1] == '@' && sscanf(line + 2, "%"SCNd64, &lsl_expiry) != 1)
+goto error;
+  /* Comment or a special comment we don't care about */
+  continue;
+}
+
+/* Leap entry */
+if (sscanf(line, "%"SCNd64" %d", &lsl_when, &lsl_tai_offset) != 2)
+  goto error;
+
+if (when == lsl_when) {
+  if (lsl_tai_offset > prev_lsl_tai_offset)
+lsl_leap = LEAP_InsertSecond;
+  else if (lsl_tai_offset < prev_lsl_tai_offset)
+lsl_leap = LEAP_DeleteSecond;
+  /* When is rounded to the end of the day, so offset hasn't changed yet! 
*/
+  *tai_offset = prev_lsl_tai_offset;
+} else if (when > lsl_when)
+  *tai_offset = lsl_tai_offset;
+
+prev_lsl_tai_offset = lsl_tai_offset;
+  }
+
+  /* Make sure the file looks sensible */
+  if (!feof(f) || !lsl_updated || !lsl_expiry)
+goto error;
+
+  if (when >= lsl_expiry)
+LOG(LOGS_WARN, "Leap second list %s needs update", leap_sec_list);
+
+  goto out;
+
+error:
+  LOG(LOGS_ERR, "Failed to parse leap seconds list %s", leap_sec_list);
+out:
+  if (f)
+fclose(f);
+  return lsl_leap;
+}
+
+/* == */
+
 static int
 check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
@@ -111,14 +199,27 @@ check_leap_source(NTP_Leap (*src)(time_t when, int 
*tai_offset))
 void
 LDB_Initialise(void)
 {
+  const char *leap_tzname, *leap_sec_list;
+
   leap_tzname = CNF_GetLeapSecTimezone();
   if (leap_tzname && !check_leap_source(get_tz_leap)) {
 LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
 leap_tzname = NULL;
   }
 
-  if (leap_tzname)
+  leap_sec_list = CNF_GetLeapSecList();
+  if (leap_sec_list && !check_leap_source(get_list_leap)) {
+LOG(LOGS_WARN, "Leap second list %s failed check, ignoring", 
leap_sec_list);
+leap_sec_list = NULL;
+  }
+
+  if (leap_sec_list) {
+LOG(LOGS_INFO, "Using leap second list %s", leap_sec_list);
+leap_src = SRC_LIST;
+  } else if (leap_tzname) {
 LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
+leap_src = SRC_TIMEZONE;
+  }
 }
 
 /* == */
@@ -139,8 +240,16 @@ LDB_GetLeap(time_t when, int *tai_offset)
   ldb_leap = LEAP_Normal;
   ldb_tai_offset = 0;
 
-  if (leap_tzname)
+  switch (leap_src) {
+  case SRC_NONE:
+break;
+  case SRC_TIMEZONE:
 ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+break;
+  case SRC_LIST:
+ldb_leap = get_list_leap(when, &ldb_tai_offset);
+break;
+  }
 
 out:
   *tai_offset = ldb_tai_offset;
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 3/5] leapdb: move source check into separate function

[patrick . oppenlander]

From: Patrick Oppenlander 

The sanity checks are valid for all possible sources of leap second
information, so move them into a separate function check_leap_source().
---
 leapdb.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 32f753a..c8a42cb 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -93,22 +93,32 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
-void
-LDB_Initialise(void)
+static int
+check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
   int tai_offset;
 
+  /* Check that the leap second source has good data for Jun 30 2012 and Dec 
31 2012 */
+  if (src(1341014400, &tai_offset) == LEAP_InsertSecond && tai_offset == 34 &&
+  src(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 35)
+return 1;
+
+  return 0;
+}
+
+/* == */
+
+void
+LDB_Initialise(void)
+{
   leap_tzname = CNF_GetLeapSecTimezone();
-  if (leap_tzname) {
-/* Check that the timezone has good data for Jun 30 2012 and Dec 31 2012 */
-if (get_tz_leap(1341014400, &tai_offset) == LEAP_InsertSecond && 
tai_offset == 34 &&
-get_tz_leap(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 
35) {
-  LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
-} else {
-  LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
-  leap_tzname = NULL;
-}
+  if (leap_tzname && !check_leap_source(get_tz_leap)) {
+LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
+leap_tzname = NULL;
   }
+
+  if (leap_tzname)
+LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 2/5] leapdb: make twice per day check logic common

[patrick . oppenlander]

From: Patrick Oppenlander 

We want to do the twice per day check regardless of the data source.
Move the check up one level from get_tz_leap() into LDB_GetLeap().
---
 leapdb.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 676a0d5..32f753a 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -41,24 +41,10 @@ static char *leap_tzname;
 static NTP_Leap
 get_tz_leap(time_t when, int *tai_offset)
 {
-  static time_t last_tz_leap_check;
-  static NTP_Leap tz_leap;
-  static int tz_tai_offset;
-
   struct tm stm, *tm;
   time_t t;
   char *tz_env, tz_orig[128];
-
-  *tai_offset = tz_tai_offset;
-
-  /* Do this check at most twice a day */
-  when = when / (12 * 3600) * (12 * 3600);
-  if (last_tz_leap_check == when)
-  return tz_leap;
-
-  last_tz_leap_check = when;
-  tz_leap = LEAP_Normal;
-  tz_tai_offset = 0;
+  NTP_Leap tz_leap = LEAP_Normal;
 
   tm = gmtime(&when);
   if (!tm)
@@ -79,7 +65,7 @@ get_tz_leap(time_t when, int *tai_offset)
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
   t = mktime(&stm);
   if (t != -1)
-tz_tai_offset = t - when + 10;
+*tai_offset = t - when + 10;
 
   /* Set the time to 23:59:60 and see how it overflows in mktime() */
   stm.tm_sec = 60;
@@ -102,8 +88,6 @@ get_tz_leap(time_t when, int *tai_offset)
   else if (stm.tm_sec == 1)
 tz_leap = LEAP_DeleteSecond;
 
-  *tai_offset = tz_tai_offset;
-
   return tz_leap;
 }
 
@@ -132,10 +116,25 @@ LDB_Initialise(void)
 NTP_Leap
 LDB_GetLeap(time_t when, int *tai_offset)
 {
-  *tai_offset = 0;
+  static time_t last_ldb_leap_check;
+  static NTP_Leap ldb_leap;
+  static int ldb_tai_offset;
+
+  /* Do this check at most twice a day */
+  when = when / (12 * 3600) * (12 * 3600);
+  if (last_ldb_leap_check == when)
+goto out;
+
+  last_ldb_leap_check = when;
+  ldb_leap = LEAP_Normal;
+  ldb_tai_offset = 0;
+
   if (leap_tzname)
-return get_tz_leap(when, tai_offset);
-  return LEAP_Normal;
+ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+
+out:
+  *tai_offset = ldb_tai_offset;
+  return ldb_leap;
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 1/5] reference: move leap second source into leapdb

[patrick . oppenlander]

offset = 0;
-
-  tm = gmtime(&when);
-  if (!tm)
-return tz_leap;
-
-  stm = *tm;
-
-  /* Temporarily switch to the timezone containing leap seconds */
-  tz_env = getenv("TZ");
-  if (tz_env) {
-if (strlen(tz_env) >= sizeof (tz_orig))
-  return tz_leap;
-strcpy(tz_orig, tz_env);
-  }
-  setenv("TZ", leap_tzname, 1);
-  tzset();
-
-  /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
-  t = mktime(&stm);
-  if (t != -1)
-tz_tai_offset = t - when + 10;
-
-  /* Set the time to 23:59:60 and see how it overflows in mktime() */
-  stm.tm_sec = 60;
-  stm.tm_min = 59;
-  stm.tm_hour = 23;
-
-  t = mktime(&stm);
-
-  if (tz_env)
-setenv("TZ", tz_orig, 1);
-  else
-unsetenv("TZ");
-  tzset();
-
-  if (t == -1)
-return tz_leap;
-
-  if (stm.tm_sec == 60)
-tz_leap = LEAP_InsertSecond;
-  else if (stm.tm_sec == 1)
-tz_leap = LEAP_DeleteSecond;
-
-  *tai_offset = tz_tai_offset;
-
-  return tz_leap;
-}
-
-/* == */
-
 static void
 leap_end_timeout(void *arg)
 {
@@ -751,16 +664,16 @@ set_leap_timeout(time_t now)
 static void
 update_leap_status(NTP_Leap leap, time_t now, int reset)
 {
-  NTP_Leap tz_leap;
+  NTP_Leap ldb_leap;
   int leap_sec, tai_offset;
 
   leap_sec = 0;
   tai_offset = 0;
 
-  if (leap_tzname && now) {
-tz_leap = get_tz_leap(now, &tai_offset);
+  if (now) {
+ldb_leap = LDB_GetLeap(now, &tai_offset);
 if (leap == LEAP_Normal)
-  leap = tz_leap;
+  leap = ldb_leap;
   }
 
   if (leap == LEAP_InsertSecond || leap == LEAP_DeleteSecond) {
@@ -1398,7 +1311,7 @@ REF_GetTaiOffset(struct timespec *ts)
 {
   int tai_offset;
 
-  get_tz_leap(ts->tv_sec, &tai_offset);
+  LDB_GetLeap(ts->tv_sec, &tai_offset);
 
   return tai_offset;
 }
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v4 0/5] support leap-seconds.list

[patrick . oppenlander]

From: Patrick Oppenlander 

Hi Miroslav,

thanks for the feedback. Here's an updated series.

Changes from v3:
* Include cut down leap second database for unit test.
* Add a comment about leap-seconds.list format to chrony.conf.adoc.
* Use UTI_OpenFile() instead of fopen(), fgets() instead of getline().
* Fix handling of blank lines while parsing leap-seconds.list.
* Comment fixes, function & enumerator naming and other minor cleanups.

Changes from v2:
* Fix copyright notices.
* Rework to avoid storing leap-seconds.list in memory, parse on the fly.
* Minimise function pointer use.
* Comment fixes, include ordering, naming and other minor cleanups.

Changes from v1:
* Add a new leapdb module with unit test.
* Make 12 hour caching logic common.
* Make sanity checking logic common.
* Don't cache leap-seconds.list contents between calls.
* Naming and other minor cleanups.

Thanks,

Patrick Oppenlander (5):
  reference: move leap second source into leapdb
  leapdb: make twice per day check logic common
  leapdb: move source check into separate function
  leapdb: support leap-seconds.list as second source
  test/unit: add leapdb test

 Makefile.in   |   2 +-
 conf.c|  14 +++
 conf.h|   1 +
 doc/chrony.conf.adoc  |  20 +++-
 leapdb.c  | 265 ++
 leapdb.h  |  37 ++
 main.c|   3 +
 reference.c   |  99 +---
 test/unit/leapdb.c|  92 +++
 test/unit/leapdb.list |  21 
 10 files changed, 457 insertions(+), 97 deletions(-)
 create mode 100644 leapdb.c
 create mode 100644 leapdb.h
 create mode 100644 test/unit/leapdb.c
 create mode 100644 test/unit/leapdb.list

-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v3 4/5] leapdb: support leap-seconds.list as second source

[Patrick Oppenlander]

On Tue, Jan 30, 2024 at 2:23 AM Miroslav Lichvar  wrote:
>
> On Thu, Dec 07, 2023 at 01:17:15PM +1100, patrick.oppenlan...@gmail.com wrote:
> > This patch adds support for getting leap second information from the
> > leap-seconds.list file included with tzdata and adds a new configuration
> > directive leapseclist to switch on the feature.
>
> Finally getting back to this patch set.

Thanks for the review, I'll submit an updated series in a few days.

Patrick

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] How to use the port configuration?

[Miroslav Lichvar]

On Wed, Jan 31, 2024 at 03:58:09PM +0100, tin...@gmail.com wrote:
> Dear All,
> 
> I am using Chrony for my system and it is working great.
> 
> I am wondering if there is a possibility to run the makestep directive
> before selection (immediately on chronyc service start) of the source is
> finished (until source is marked as *)

If no source is selected, how would it know the offset that needs to
be corrected by stepping the clock?

There is the initstepslew directive to use a different set of servers
for the initial correction, but the selection still happens.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v3 5/5] test/unit: add leapdb test

[Miroslav Lichvar]

On Mon, Jan 29, 2024 at 04:29:00PM +0100, Miroslav Lichvar wrote:
> On Thu, Dec 07, 2023 at 01:17:16PM +1100, patrick.oppenlan...@gmail.com wrote:
> > +void
> > +test_unit(void)
> > +{
> > +  char conf[][100] = {
> > +"leapsectz right/UTC",
> > +"leapseclist /usr/share/zoneinfo/leap-seconds.list"
> > +  };
> 
> The test should not fail on non-glibc systems and when the list file is
> missing. It should skip instead. 

For testing the list parsing, maybe it's best to include a cut-down
list with only few entries and few lines of comment (not the full 10KB
file) as leapdb.list directly in the unit test directory, similarly to
the ntp_core.keys file.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v3 5/5] test/unit: add leapdb test

[Miroslav Lichvar]

On Thu, Dec 07, 2023 at 01:17:16PM +1100, patrick.oppenlan...@gmail.com wrote:
> diff --git a/test/unit/leapdb.c b/test/unit/leapdb.c

> +struct test_vector {
> +  time_t when;
> +  int tai_offset;
> +  NTP_Leap leap;
> +} tests[] = {
> +  /* From leap-seconds.list */
> +  {2272060800, 10, LEAP_Normal}, // 1 Jan 1972

Please use the classic C comment syntax /* */.

> +void
> +test_unit(void)
> +{
> +  char conf[][100] = {
> +"leapsectz right/UTC",
> +"leapseclist /usr/share/zoneinfo/leap-seconds.list"
> +  };

The test should not fail on non-glibc systems and when the list file is
missing. It should skip instead. 

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] [PATCH v3 4/5] leapdb: support leap-seconds.list as second source

[Miroslav Lichvar]

On Thu, Dec 07, 2023 at 01:17:15PM +1100, patrick.oppenlan...@gmail.com wrote:
> This patch adds support for getting leap second information from the
> leap-seconds.list file included with tzdata and adds a new configuration
> directive leapseclist to switch on the feature.

Finally getting back to this patch set.

> diff --git a/doc/chrony.conf.adoc b/doc/chrony.conf.adoc

> +[[leapseclist]]*leapseclist* _file_::
> +This directive specifies the path to a file containing a list of leap 
> seconds.

Can you please add few words about the file format, maybe simply
describe it as the NIST format? It contains not just the leap seconds,
but also the TAI-UTC offset.

> diff --git a/leapdb.c b/leapdb.c

> +enum {
> +  SRC_NONE,
> +  SRC_TZ,
> +  SRC_LEAP_SEC_LIST,
> +} leap_src;

The enum naming seems inconsistent. Maybe "SRC_TIMEZONE" and
"SRC_LIST" would look better?

> +
> +/* Offset between leap-seconds.list timestamp epoch and Unix epoch.
> +   leap-seconds.list epoch is 1 Jan 1900, 00:00:00 */
> +static const long long LEAP_SEC_LIST_OFFSET = 2208988800;

This should be a macro.

> @@ -93,6 +102,78 @@ get_tz_leap(time_t when, int *tai_offset)
>  
>  /* == */
>  
> +static NTP_Leap
> +get_leap_sec_list_leap(time_t when, int *tai_offset)

Or shorter get_list_leap()?

> +{
> +  FILE *f;
> +  char *line = NULL;
> +  size_t linelen = 0;
> +  NTP_Leap lsl_leap = LEAP_Normal;
> +  int prev_lsl_tai_offset = 10;
> +  long long lsl_updated = 0, lsl_expiry = 0;

I think these should be int64_t and SCNd64 format in sscanf.

> +  if (!(f = fopen(CNF_GetLeapSecList(), "r"))) {

Use UTI_OpenFile() here. It will print an error message. And maybe
add a variable to save the return value of CNF_GetLeapSecList(), so it
doesn't have to be called multiple times in the same function?

> +  while (getline(&line, &linelen, f) > 0) {

Please use fgets() as used in all other file parsing.

> +long long lsl_when;

int64_t

> +int lsl_tai_offset;
> +
> +if (*line == '#') {
> +  /* Update time line starts with #$ */
> +  if (line[1] == '$' && sscanf(line + 2, "%lld", &lsl_updated) != 1)
> +goto error;
> +  /* Expiration time line starts with #@ */
> +  if (line[1] == '@' && sscanf(line + 2, "%lld", &lsl_expiry) != 1)
> +goto error;
> +  /* Comment or a special comment we don't care about */
> +  continue;
> +}
> +
> +/* Leap entry */
> +if (sscanf(line, "%lld %d", &lsl_when, &lsl_tai_offset) != 2)
> +  goto error;
> +
> +if (when == lsl_when) {
> +  if (lsl_tai_offset > prev_lsl_tai_offset)
> +lsl_leap = LEAP_InsertSecond;
> +  else if (lsl_tai_offset < prev_lsl_tai_offset)
> +lsl_leap = LEAP_DeleteSecond;
> +  /* When is rounded to the end of the day, so offset hasn't changed 
> yet! */
> +  *tai_offset = prev_lsl_tai_offset;
> +} else if (when > lsl_when)
> +  *tai_offset = lsl_tai_offset;
> +
> +prev_lsl_tai_offset = lsl_tai_offset;
> +  }
> +
> +  /* Make sure the file looks sensible */
> +  if (!feof(f) || !lsl_updated || !lsl_expiry)
> +goto error;
> +
> +  if (when >= lsl_expiry)
> +LOG(LOGS_WARN, "Leap second list %s needs update", CNF_GetLeapSecList());
> +
> +  goto out;
> +
> +error:
> +  LOG(LOGS_ERR, "Failed to parse leap seconds list %s", 
> CNF_GetLeapSecList());
> +out:
> +  if (f)
> +fclose(f);
> +  return lsl_leap;
> +}
> +
> +/* == */
> +
>  static int
>  check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
>  {
> @@ -111,14 +192,30 @@ check_leap_source(NTP_Leap (*src)(time_t when, int 
> *tai_offset))
>  void
>  LDB_Initialise(void)
>  {
> -  leap_tzname = CNF_GetLeapSecTimezone();
> +  const char *leap_tzname = CNF_GetLeapSecTimezone();
>if (leap_tzname && !check_leap_source(get_tz_leap)) {
>  LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
> leap_tzname);
>  leap_tzname = NULL;
>}
>  
> -  if (leap_tzname)
> +  const char *leap_sec_list = CNF_GetLeapSecList();

Declarations should be at the beginning of the function.

> +  if (leap_sec_list && !check_leap_source(get_leap_sec_list_leap)) {
> +LOG(LOGS_WARN, "Leap second list %s failed check, ignoring", 
> leap_sec_list);
> +leap_sec_list = NULL;
> +  }
> +
> +  if (leap_sec_list && leap_tzname) {
> +LOG(LOGS_WARN, "Multiple leap second sources, ignoring leapsectz");
> +leap_tzname = NULL;

This warning doesn't seem necessary to me. Info message for the first
working source is fine. It doesn't have to check both.

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] SNMP agent

[Marko Hrastovec]

It would be nice if some of the values that cannot be obtained would be 
available via libchrony.
I will try to implement the ones that are clarified here.

Regarding low interest in the MIB in NTP WG I can understand it. However, we 
work in a business
where we monitor many systems and applications centrally (via SNMP), and NTP is 
one of
the key elements, and some of our applications are criticaly dependent on 
accurate time source
(multilateration, tracking,...). We monitor a lot of system parameters (CPU 
utilization, disk space,
memory utilization, etc.) via SNMP, and it would be very useful if we would be 
able to monitor
NTP with the same software. We have stratum 1 time sources synchonized with 
GPS, DCF,... which
can be easily jammed. Since the start of war in Ukraine and in Israel and 
Palestine, GNSS jamming
is more and more frequent and problematic. Therefore, monitoring chrony via 
SNMP would be very
beneficial probably not NTP WG, but for users.

On Thu, 2024-01-04 at 14:40 +0100, Miroslav Lichvar wrote:
On Thu, Dec 07, 2023 at 10:53:29AM +, Marko Hrastovec wrote:
libchrony looks like a good way to get the data from chrony and provide them
via SNMP.

I have started a project here https://gitlab.com/markoh/chronysnmpd

Great.

The application builds and returns some data form chrony. However, NTPv4-MIB
was constructed with ntpd in mind and provides information more suited for ntpd.

Same problem is with the monitoring/control NTP mode 6. It assumes NTP
implementations have the same algorithms as ntpd. This is a frequent
topic in the NTP working group. There is some concensus that NTPv5
specification shouldn't prescribe any algorithms.

 *   ntpEntSoftwareVersion cannot be obtained via libchrony

There could be a new command for that and some other things below,
maybe called "serverinfo".

 *   ntpEntTimeResolution cannot be obtained via libchrony

I think this would be 1 nanosecond on all currently supported systems
in their latest versions.

 *   ntpEntTimePrecision not sure which value from libchrony to use

You could get it from an NTP response.

 *   ntpEntTimeDistance not sure which value from libchrony to use 
(probably "Last offset")

This would be root delay / 2 + root dispersion from the tracking report.

 *   ntpEntStatusEntityUptime cannot be obtained

Could be in serverinfo.

 *   ntpEntStatusLeapSecond cannot be obtained

Could be calculated from the leap status in tracking report as
midnight UTC of the current day.

 *   ntpEntStatusLeapSecDirection cannot be obtained

+1 or -1 per the leap status.

There are two options for minimize the difference between NTPv4-MIB and 
libchrony. First is
to add some values to libchrony. Second is to try to update NTPv4-MIB which is 
outdated and
was probably never used in full scale. The best would be the combination of 
both ways.

A new command to get some of the details would make sense to me. I can
look into it.

But at least in the NTP WG, I don't see much interest in the MIB. The
future seems to be the Yang model, see RFC 9249.

--
Miroslav Lichvar

[chrony-dev] [Git][chrony/chrony][master] ntp: fix authenticated requests in serverstats

[Miroslav Lichvar (@mlichvar)]

Miroslav Lichvar pushed to branch master at chrony / chrony


Commits:
e11b518a by Miroslav Lichvar at 2024-01-08T11:46:32+01:00
ntp: fix authenticated requests in serverstats

Fix the CLG_UpdateNtpStats() call to count requests passing the
authentication check instead of requests triggering a KoD response
(i.e. NTS NAK).

- - - - -


2 changed files:

- ntp_core.c
- test/system/010-nts


View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/e11b518a1ffa704986fb1f1835c425844ba248ef

-- 
View it on GitLab: 
https://gitlab.com/chrony/chrony/-/commit/e11b518a1ffa704986fb1f1835c425844ba248ef
You're receiving this email because of your account on gitlab.com.

Re: [chrony-dev] SNMP agent

[Miroslav Lichvar]

On Thu, Dec 07, 2023 at 10:53:29AM +, Marko Hrastovec wrote:
> libchrony looks like a good way to get the data from chrony and provide them
> via SNMP.
> 
> I have started a project here https://gitlab.com/markoh/chronysnmpd

Great.

> The application builds and returns some data form chrony. However, NTPv4-MIB
> was constructed with ntpd in mind and provides information more suited for 
> ntpd.

Same problem is with the monitoring/control NTP mode 6. It assumes NTP
implementations have the same algorithms as ntpd. This is a frequent
topic in the NTP working group. There is some concensus that NTPv5
specification shouldn't prescribe any algorithms.

>  *   ntpEntSoftwareVersion cannot be obtained via libchrony

There could be a new command for that and some other things below,
maybe called "serverinfo".

>  *   ntpEntTimeResolution cannot be obtained via libchrony

I think this would be 1 nanosecond on all currently supported systems
in their latest versions.

>  *   ntpEntTimePrecision not sure which value from libchrony to use

You could get it from an NTP response.

>  *   ntpEntTimeDistance not sure which value from libchrony to use 
> (probably "Last offset")

This would be root delay / 2 + root dispersion from the tracking report.

>  *   ntpEntStatusEntityUptime cannot be obtained

Could be in serverinfo.

>  *   ntpEntStatusLeapSecond cannot be obtained

Could be calculated from the leap status in tracking report as
midnight UTC of the current day.

>  *   ntpEntStatusLeapSecDirection cannot be obtained

+1 or -1 per the leap status.

> There are two options for minimize the difference between NTPv4-MIB and 
> libchrony. First is
> to add some values to libchrony. Second is to try to update NTPv4-MIB which 
> is outdated and
> was probably never used in full scale. The best would be the combination of 
> both ways.

A new command to get some of the details would make sense to me. I can
look into it.

But at least in the NTP WG, I don't see much interest in the MIB. The
future seems to be the Yang model, see RFC 9249.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Tue, Dec 12, 2023 at 04:34:09PM +0300, CpServiceSPb wrote:
>  Hallelujah.
> It has worked.
Great.

> One question remained - how to bind client instances to the exact wan
> interface, not to 0.0.0.0 ?

The client's sockets can be bound to an address with the
bindacqaddress directive.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

 Hallelujah.
It has worked.
I will think about how to make an appropriate start/stop script.

> That suggests there is an unexpected chronyd instance running on the
system, maybe from a previous test which > wasn't terminated properly?
I investigated.
It is when lan/dmz config files are located in the folder specified as
conf.d in chrony.conf.

One question remained - how to bind client instances to the exact wan
interface, not to 0.0.0.0 ?




вт, 12 дек. 2023 г. в 16:26, Miroslav Lichvar :

> On Tue, Dec 12, 2023 at 04:07:23PM +0300, CpServiceSPb wrote:
> > Let' s clarify:
>
> Yes, that looks good to me. Make sure no other chronyd instance is
> running before you start those three.
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Tue, Dec 12, 2023 at 04:07:23PM +0300, CpServiceSPb wrote:
> Let' s clarify:

Yes, that looks good to me. Make sure no other chronyd instance is
running before you start those three.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

Let' s clarify:

==
chronyd -f /etc/chrony-server-lan.conf
where /etc/chrony-server-lan.conf:
server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
bindaddress lanIP
allow
cmdport 11323
bindcmdaddress /var/run/chrony/chronyd-server-lan.sock
pidfile /var/run/chronyd-server-lan.pid
driftfile /var/lib/chrony/drift-server-lan

==
chronyd -f /etc/chrony-server-dmz.conf
where /etc/chrony-server-dmz.conf:
server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
bindaddress dmzIP
allow
cmdport 11324
bindcmdaddress /var/run/chrony/chronyd-server-dmz.sock
pidfile /var/run/chronyd-server-dmz.pid
driftfile /var/lib/chrony/drift-server-dmz


==
chronyd -f /etc/chrony-client-upstream.conf
where  /etc/chrony-client-upstream.conf :
pool pool.ntp.org iburst
allow 127.0.0.1
port 11123
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync

вт, 12 дек. 2023 г. в 16:00, Miroslav Lichvar :

> On Tue, Dec 12, 2023 at 03:49:10PM +0300, CpServiceSPb wrote:
> > I will check about unexpected chrony instances.
> > I use Ubuntu 22.04 LTS x64.
> >
> > Should I use the config you posted above and multi script or config and
> > chrony -d ?
>
> Don't use the script. It cannot set different bindaddresses. It was
> just an example showing how multiple instances can be started. You
> should create the three configs (1 client + 2 servers) at some
> location and run
>
> chronyd -f /etc/chrony.conf.1
> chronyd -f /etc/chrony.conf.2
> chronyd -f /etc/chrony.conf.3
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Tue, Dec 12, 2023 at 03:49:10PM +0300, CpServiceSPb wrote:
> I will check about unexpected chrony instances.
> I use Ubuntu 22.04 LTS x64.
> 
> Should I use the config you posted above and multi script or config and
> chrony -d ?

Don't use the script. It cannot set different bindaddresses. It was
just an example showing how multiple instances can be started. You
should create the three configs (1 client + 2 servers) at some
location and run

chronyd -f /etc/chrony.conf.1
chronyd -f /etc/chrony.conf.2
chronyd -f /etc/chrony.conf.3

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

I will check about unexpected chrony instances.
I use Ubuntu 22.04 LTS x64.

Should I use the config you posted above and multi script or config and
chrony -d ?


вт, 12 дек. 2023 г. в 15:23, Miroslav Lichvar :

> On Mon, Dec 11, 2023 at 06:04:18PM +0300, CpServiceSPb wrote:
> > Which ports will be listened to, 123 ?
> > I mean by server from clients in ln/dmz ?
>
> Yes, 123.
>
> > I did such a configuration.
> >
> > Launched as chronyd -d ang got:
> > Could not add source 127.0.0.1
>
> That would indicate you have the same source specified multiple times
> in the config. Try the configs I posted. They have only one source
> specified.
>
> > If I launched via multi script I got:
> > Starting server instance #1
> > Starting server instance #2
> > Starting server instance #3
> > Starting server instance #4
> > Starting client instance
> > Fatal error : Another chronyd may already be running (pid=135687), check
> > /var/run/chrony/chronyd-server2.pid
>
> That suggests there is an unexpected chronyd instance running on the
> system, maybe from a previous test which wasn't terminated properly?
> See what process has the PID 135687.
>
> Maybe your system is cursed and cannot run chrony as expected.
> Try ntpsec. It should be easier to configure for your requirements.
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Mon, Dec 11, 2023 at 06:04:18PM +0300, CpServiceSPb wrote:
> Which ports will be listened to, 123 ?
> I mean by server from clients in ln/dmz ?

Yes, 123.

> I did such a configuration.
> 
> Launched as chronyd -d ang got:
> Could not add source 127.0.0.1

That would indicate you have the same source specified multiple times
in the config. Try the configs I posted. They have only one source
specified.

> If I launched via multi script I got:
> Starting server instance #1
> Starting server instance #2
> Starting server instance #3
> Starting server instance #4
> Starting client instance
> Fatal error : Another chronyd may already be running (pid=135687), check
> /var/run/chrony/chronyd-server2.pid

That suggests there is an unexpected chronyd instance running on the
system, maybe from a previous test which wasn't terminated properly?
See what process has the PID 135687.

Maybe your system is cursed and cannot run chrony as expected.
Try ntpsec. It should be easier to configure for your requirements.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

I did such a configuration.

Launched as chronyd -d ang got:
Could not add source 127.0.0.1

and netstat -anupt | grep 123
udp0  0 127.0.0.1:35180 127.0.0.1:11123
ESTABLISHED 135185/chronyd
udp0  0 dmzIP:11123  0.0.0.0:*
135185/chronyd

If I launched via multi script I got:
Starting server instance #1
Starting server instance #2
Starting server instance #3
Starting server instance #4
Starting client instance
Fatal error : Another chronyd may already be running (pid=135687), check
/var/run/chrony/chronyd-server2.pid

and netstat:
udp0  0 0.0.0.0:123 0.0.0.0:*
136025/chronyd
udp0  0 0.0.0.0:123 0.0.0.0:*
136024/chronyd
udp0  0 0.0.0.0:123 0.0.0.0:*
136022/chronyd
udp0  0 127.0.0.1:11123 0.0.0.0:*
136026/chronyd

I supposed to get something looks like:
udp0  lanIP:123 0.0.0.0:*
136025/chronyd
udp0  dmzIP:123 0.0.0.0:*
136024/chronyd
udp0  0 127.0.0.1:11123 0.0.0.0:*
136026/chronyd

Or am I wromg ?

пн, 11 дек. 2023 г. в 18:04, CpServiceSPb :

> Which ports will be listened to, 123 ?
> I mean by server from clients in ln/dmz ?
>
>
>
> пн, 11 дек. 2023 г. в 17:26, Miroslav Lichvar :
>
>> On Mon, Dec 11, 2023 at 05:08:32PM +0300, CpServiceSPb wrote:
>> > Would you be so kind to post 2 config files for 2 different interfaces,
>> for
>> > example:
>> > lan = 192.168.0.254/99
>> > dmz = 172.17.0.254/99
>>
>> 1st server instance:
>> server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
>> bindaddress 192.168.0.254
>> allow
>> cmdport 11323
>> bindcmdaddress /var/run/chrony/chronyd-server1.sock
>> pidfile /var/run/chronyd-server1.pid
>> driftfile /var/lib/chrony/drift-server1
>>
>> 2nd server instance:
>> server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
>> bindaddress 172.17.0.254
>> allow
>> cmdport 11324
>> bindcmdaddress /var/run/chrony/chronyd-server2.sock
>> pidfile /var/run/chronyd-server2.pid
>> driftfile /var/lib/chrony/drift-server2
>>
>> client instance synchornizing clock and providing time to the server
>> instances:
>> pool pool.ntp.org iburst
>> allow 127.0.0.1
>> port 11123
>> driftfile /var/lib/chrony/drift
>> makestep 1 3
>> rtcsync
>>
>> --
>> Miroslav Lichvar
>>
>>
>> --
>> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
>> "unsubscribe" in the subject.
>> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in
>> the subject.
>> Trouble?  Email listmas...@chrony.tuxfamily.org.
>>
>>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

Which ports will be listened to, 123 ?
I mean by server from clients in ln/dmz ?



пн, 11 дек. 2023 г. в 17:26, Miroslav Lichvar :

> On Mon, Dec 11, 2023 at 05:08:32PM +0300, CpServiceSPb wrote:
> > Would you be so kind to post 2 config files for 2 different interfaces,
> for
> > example:
> > lan = 192.168.0.254/99
> > dmz = 172.17.0.254/99
>
> 1st server instance:
> server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
> bindaddress 192.168.0.254
> allow
> cmdport 11323
> bindcmdaddress /var/run/chrony/chronyd-server1.sock
> pidfile /var/run/chronyd-server1.pid
> driftfile /var/lib/chrony/drift-server1
>
> 2nd server instance:
> server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
> bindaddress 172.17.0.254
> allow
> cmdport 11324
> bindcmdaddress /var/run/chrony/chronyd-server2.sock
> pidfile /var/run/chronyd-server2.pid
> driftfile /var/lib/chrony/drift-server2
>
> client instance synchornizing clock and providing time to the server
> instances:
> pool pool.ntp.org iburst
> allow 127.0.0.1
> port 11123
> driftfile /var/lib/chrony/drift
> makestep 1 3
> rtcsync
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Mon, Dec 11, 2023 at 05:08:32PM +0300, CpServiceSPb wrote:
> Would you be so kind to post 2 config files for 2 different interfaces, for
> example:
> lan = 192.168.0.254/99
> dmz = 172.17.0.254/99

1st server instance:
server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
bindaddress 192.168.0.254
allow
cmdport 11323
bindcmdaddress /var/run/chrony/chronyd-server1.sock
pidfile /var/run/chronyd-server1.pid
driftfile /var/lib/chrony/drift-server1

2nd server instance:
server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
bindaddress 172.17.0.254
allow
cmdport 11324
bindcmdaddress /var/run/chrony/chronyd-server2.sock
pidfile /var/run/chronyd-server2.pid
driftfile /var/lib/chrony/drift-server2

client instance synchornizing clock and providing time to the server
instances:
pool pool.ntp.org iburst
allow 127.0.0.1
port 11123
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[CpServiceSPb]

Would you be so kind to post 2 config files for 2 different interfaces, for
example:
lan = 192.168.0.254/99
dmz = 172.17.0.254/99

and multiple launching script.

пн, 11 дек. 2023 г. в 17:05, Miroslav Lichvar :

> On Thu, Dec 07, 2023 at 12:33:57AM +0300, CpServiceSPb wrote:
> > I really don't understand how to specify the interface address for each
> > instance.
> > Here are my config files:
> > *conf.d/lan.conf*
> > server lanIP port 11123 minpoll 0 maxpoll 0 copy
> > allow
> > bindcmdaddress /var/run/chrony/chronyd-server_lan.sock
> > cmdport 11323
> > pidfile /var/run/chrony/chronyd-server_lan.pid
> > driftfile /var/lib/chrony/drift-server_lan
>
> There should be a bindaddress or binddevice directive.
>
> --
> Miroslav Lichvar
>
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-dev] Multihomed (multiple) network interfaces support !

[Miroslav Lichvar]

On Thu, Dec 07, 2023 at 12:33:57AM +0300, CpServiceSPb wrote:
> I really don't understand how to specify the interface address for each
> instance.
> Here are my config files:
> *conf.d/lan.conf*
> server lanIP port 11123 minpoll 0 maxpoll 0 copy
> allow
> bindcmdaddress /var/run/chrony/chronyd-server_lan.sock
> cmdport 11323
> pidfile /var/run/chrony/chronyd-server_lan.pid
> driftfile /var/lib/chrony/drift-server_lan

There should be a bindaddress or binddevice directive.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] SNMP agent

[Marko Hrastovec]

libchrony looks like a good way to get the data from chrony and provide them
via SNMP.

I have started a project here https://gitlab.com/markoh/chronysnmpd

The application builds and returns some data form chrony. However, NTPv4-MIB
was constructed with ntpd in mind and provides information more suited for ntpd.
Some data can be extracted with libchrony, but not all. If you look at the 
attached
html there is the whole MIB tree for NTP.


  *   ntpEntNotifications are not implemented yet.
  *   ntpEntInfo is partially implemented:
 *   ntpEntSoftwareVersion cannot be obtained via libchrony
 *   ntpEntSoftwareVendor cannot be obtained via libchrony
 *   ntpEntTimeResolution cannot be obtained via libchrony
 *   ntpEntTimePrecision not sure which value from libchrony to use
 *   ntpEntTimeDistance not sure which value from libchrony to use 
(probably "Last offset")
  *   - ntpEntStatus is partially implemented:
 *   ntpEntStatusCurrentMode can only be obtained partially
 *   ntpEntStatusActiveOffset to be implemented
 *   ntpEntStatusActiveRefSourceName to be implemented
 *   ntpEntStatusDispersion to be implemented
 *   ntpEntStatusEntityUptime cannot be obtained
 *   ntpEntStatusDateTime to be implemented
 *   ntpEntStatusLeapSecond cannot be obtained
 *   ntpEntStatusLeapSecDirection cannot be obtained
 *   ntpEntStatusInPkts cannot be obtained
 *   ntpEntStatusOutPkts cannot be obtained
 *   ntpEntStatusBadVersion cannot be obtained
 *   ntpEntStatusProtocolError cannot be obtained
 *   ntpEntStatusNotifications cannot be obtained
 *   ntpEntStatPktModeTable cannot be obtained
  *   ntpAssociationTable implemented
  *   ntpAssociationStatisticsTable implemented
  *   ntpEntControl not implemented
  *   ntpEntNotifObjects not implemented

Obviously some things can be obtained from libchrony and some cannot. For some 
it would
be sensible to implement them in libchrony (version, etc). For some it would 
not be ok to
implement because chrony works differently.

I am not sure I got the right values from libchrony for the fields that are 
implemented.

There are two options for minimize the difference between NTPv4-MIB and 
libchrony. First is
to add some values to libchrony. Second is to try to update NTPv4-MIB which is 
outdated and
was probably never used in full scale. The best would be the combination of 
both ways.

As I mentioned I found a project for ntpsnmpd which looks unfinished. Is there 
an interest
in chrony community to update libchrony and to invest time for NTPv4-MIB update.

If none of the above will be done, we can still make the best that can be done 
in chronysnmpd
to provide at least the information that is currently available.

On Tue, 2023-11-14 at 09:53 +0100, Miroslav Lichvar wrote:
On Tue, Nov 14, 2023 at 07:59:38AM +, Marko Hrastovec wrote:
There is already a standard MIB
(https://datatracker.ietf.org/doc/html/rfc5907) for ntp monitoring. I
propose to make an agentX or subagent for snmpd in chrony, which would
report ntp status via snmpd using a provided MIB. More information
about subagents can be found here
https://net-snmp.sourceforge.io/wiki/index.php/TUT:Writing_a_Subagent

I am willing to contribute the code, but I am unfamiliar with chrony
source. Is there an interest or will to incorporate the SNMP monitoring
into chrony or not?

I think it should be a separate project using the cmdmon protocol for
communication with chronyd as used by chronyc. With this library it
should be easy

https://gitlab.com/chrony/libchrony

Note that it's still in early stages of development and the API might
change.

--
Miroslav Lichvar



Title: MIB information for ntpSnmpMIB


INTRODUCTION


This is a summary of information regarding objects below the ntpSnmpMIB
MIB object, which is defined within the NTPv4-MIB MIB
document as .1.3.6.1.2.1.197.


TABLE OF CONTENTS

Current Objects

Scalars
  ntpEntStatPktModeTable
  ntpAssociationTable
  ntpAssociationStatisticsTable

Deprecated Objects

Deprecated Scalars

Notifications
Textual Conventions
Tree-based view



SCALAR OBJECTS


NameTypeAccessOIDDescription
  
  

1
ntpEntSoftwareName


  OCTETSTR
  Legal Lengths:
0 .. 255
 
 Utf8String

  ReadOnly
.1.3.6.1.2.1.197.1.1.1


Note: this object is based on the  Utf8String TEXTUAL-CONVENTION.


The product name of the running NTP version, e.g., 'ntpd'.


  
  
  

2
ntpEntSoftwareVersion


  OCTETSTR
  Legal Lengths:
0 .. 255
 
 Utf8String

  ReadOnly
.1.3.6.1.2.1.197.1.1.2


Note: this object is based on the  Utf8String TEXTUAL-CONVENTION.


The software version of the installed NTP implementation
as a full version string, e.g., 'ntpd-4.2.0b.1433 ...'


  
  
  

3
ntpEntSoftwareVendor


  OCTETSTR
  Legal Lengths:
0 .. 255
 
 Utf8String

  ReadOnly
.1.3.6.1.2.1.197.1.1.3


Note: this object is based on the  Utf8String TEXTUAL-CONVENTION.


The vendor/author of the installed

Re: [chrony-dev] [PATCH v3 2/5] leapdb: make twice per day check logic common

[Patrick Oppenlander]

On Thu, Dec 7, 2023 at 1:24 PM Bill Unruh  wrote:
>
> Why twice per day? Leapseconds occur at most twice per year (and recently 0
> times per year for the past 7 years). So, if you want, do it at UTC 00:00 on
> Jun 30 and Dec 31.

Hi Bill,

I've added chrony-dev to CC.

This patch just reorganises the existing code and (hopefully)
maintains the current behaviour. I've been careful to try not to
change existing behaviour in this area in an attempt to avoid
introducing bugs.

I believe the original intention is to detect updates to the system
timezone database, although, as you correctly point out, the check
could potentially be more infrequent.

As it stands, doing it twice a day seems pretty harmless to me.

Patrick

> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
> Canada V6T 1Z1 | and Gravity __|_theory.physics.ubc.ca/
>
> On Thu, 7 Dec 2023, patrick.oppenlan...@gmail.com wrote:
>
> > [CAUTION: Non-UBC Email]
> >
> > From: Patrick Oppenlander 
> >
> > We want to do the twice per day check regardless of the data source.
> > Move the check up one level from get_tz_leap() into LDB_GetLeap().
> > ---
> > leapdb.c | 41 -
> > 1 file changed, 20 insertions(+), 21 deletions(-)
> >
> > diff --git a/leapdb.c b/leapdb.c
> > index 676a0d5..32f753a 100644
> > --- a/leapdb.c
> > +++ b/leapdb.c
> > @@ -41,24 +41,10 @@ static char *leap_tzname;
> > static NTP_Leap
> > get_tz_leap(time_t when, int *tai_offset)
> > {
> > -  static time_t last_tz_leap_check;
> > -  static NTP_Leap tz_leap;
> > -  static int tz_tai_offset;
> > -
> >   struct tm stm, *tm;
> >   time_t t;
> >   char *tz_env, tz_orig[128];
> > -
> > -  *tai_offset = tz_tai_offset;
> > -
> > -  /* Do this check at most twice a day */
> > -  when = when / (12 * 3600) * (12 * 3600);
> > -  if (last_tz_leap_check == when)
> > -  return tz_leap;
> > -
> > -  last_tz_leap_check = when;
> > -  tz_leap = LEAP_Normal;
> > -  tz_tai_offset = 0;
> > +  NTP_Leap tz_leap = LEAP_Normal;
> >
> >   tm = gmtime(&when);
> >   if (!tm)
> > @@ -79,7 +65,7 @@ get_tz_leap(time_t when, int *tai_offset)
> >   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
> >   t = mktime(&stm);
> >   if (t != -1)
> > -tz_tai_offset = t - when + 10;
> > +*tai_offset = t - when + 10;
> >
> >   /* Set the time to 23:59:60 and see how it overflows in mktime() */
> >   stm.tm_sec = 60;
> > @@ -102,8 +88,6 @@ get_tz_leap(time_t when, int *tai_offset)
> >   else if (stm.tm_sec == 1)
> > tz_leap = LEAP_DeleteSecond;
> >
> > -  *tai_offset = tz_tai_offset;
> > -
> >   return tz_leap;
> > }
> >
> > @@ -132,10 +116,25 @@ LDB_Initialise(void)
> > NTP_Leap
> > LDB_GetLeap(time_t when, int *tai_offset)
> > {
> > -  *tai_offset = 0;
> > +  static time_t last_ldb_leap_check;
> > +  static NTP_Leap ldb_leap;
> > +  static int ldb_tai_offset;
> > +
> > +  /* Do this check at most twice a day */
> > +  when = when / (12 * 3600) * (12 * 3600);
> > +  if (last_ldb_leap_check == when)
> > +    goto out;
> > +
> > +  last_ldb_leap_check = when;
> > +  ldb_leap = LEAP_Normal;
> > +  ldb_tai_offset = 0;
> > +
> >   if (leap_tzname)
> > -return get_tz_leap(when, tai_offset);
> > -  return LEAP_Normal;
> > +ldb_leap = get_tz_leap(when, &ldb_tai_offset);
> > +
> > +out:
> > +  *tai_offset = ldb_tai_offset;
> > +  return ldb_leap;
> > }
> >
> > /* == */
> > --
> > 2.43.0
> >
> >
> > --
> > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with 
> > "unsubscribe" in the subject.
> > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
> > subject.
> > Trouble?  Email listmas...@chrony.tuxfamily.org.
> >
> >

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v3 5/5] test/unit: add leapdb test

[patrick . oppenlander]

From: Patrick Oppenlander 

---
 test/unit/leapdb.c | 117 +
 1 file changed, 117 insertions(+)
 create mode 100644 test/unit/leapdb.c

diff --git a/test/unit/leapdb.c b/test/unit/leapdb.c
new file mode 100644
index 000..ac5d86d
--- /dev/null
+++ b/test/unit/leapdb.c
@@ -0,0 +1,117 @@
+/*
+ **
+ * Copyright (C) Patrick Oppenlander 2023
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ **
+ */
+
+#include 
+#include "test.h"
+
+struct test_vector {
+  time_t when;
+  int tai_offset;
+  NTP_Leap leap;
+} tests[] = {
+  /* From leap-seconds.list */
+  {2272060800, 10, LEAP_Normal}, // 1 Jan 1972
+  {2287785600, 11, LEAP_InsertSecond}, // 1 Jul 1972
+  {2303683200, 12, LEAP_InsertSecond}, // 1 Jan 1973
+  {2335219200, 13, LEAP_InsertSecond}, // 1 Jan 1974
+  {2366755200, 14, LEAP_InsertSecond}, // 1 Jan 1975
+  {2398291200, 15, LEAP_InsertSecond}, // 1 Jan 1976
+  {2429913600, 16, LEAP_InsertSecond}, // 1 Jan 1977
+  {2461449600, 17, LEAP_InsertSecond}, // 1 Jan 1978
+  {2492985600, 18, LEAP_InsertSecond}, // 1 Jan 1979
+  {2524521600, 19, LEAP_InsertSecond}, // 1 Jan 1980
+  {2571782400, 20, LEAP_InsertSecond}, // 1 Jul 1981
+  {2603318400, 21, LEAP_InsertSecond}, // 1 Jul 1982
+  {2634854400, 22, LEAP_InsertSecond}, // 1 Jul 1983
+  {2698012800, 23, LEAP_InsertSecond}, // 1 Jul 1985
+  {2776982400, 24, LEAP_InsertSecond}, // 1 Jan 1988
+  {2840140800, 25, LEAP_InsertSecond}, // 1 Jan 1990
+  {2871676800, 26, LEAP_InsertSecond}, // 1 Jan 1991
+  {2918937600, 27, LEAP_InsertSecond}, // 1 Jul 1992
+  {2950473600, 28, LEAP_InsertSecond}, // 1 Jul 1993
+  {2982009600, 29, LEAP_InsertSecond}, // 1 Jul 1994
+  {3029443200, 30, LEAP_InsertSecond}, // 1 Jan 1996
+  {3076704000, 31, LEAP_InsertSecond}, // 1 Jul 1997
+  {3124137600, 32, LEAP_InsertSecond}, // 1 Jan 1999
+  {3345062400, 33, LEAP_InsertSecond}, // 1 Jan 2006
+  {3439756800, 34, LEAP_InsertSecond}, // 1 Jan 2009
+  {3550089600, 35, LEAP_InsertSecond}, // 1 Jul 2012
+  {3644697600, 36, LEAP_InsertSecond}, // 1 Jul 2015
+  {3692217600, 37, LEAP_InsertSecond}, // 1 Jan 2017
+};
+
+static void
+test_leap_source(NTP_Leap (*fn)(time_t when, int *tai_offset))
+{
+  TEST_CHECK(check_leap_source(fn));
+
+  /* Test every leap second to date */
+  int prev_tai_offset = 10;
+  for (int i = 0; i < sizeof tests / sizeof tests[0]; ++i) {
+struct test_vector *t = tests + i;
+
+NTP_Leap leap;
+int tai_offset = -1;
+
+/* One second before leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET - 1, &tai_offset);
+TEST_CHECK(leap == t->leap);
+TEST_CHECK(tai_offset = prev_tai_offset);
+
+/* Exactly on leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+/* One second after leap second */
+leap = fn(t->when - LEAP_SEC_LIST_OFFSET + 1, &tai_offset);
+TEST_CHECK(leap == LEAP_Normal);
+TEST_CHECK(tai_offset == t->tai_offset);
+
+prev_tai_offset = t->tai_offset;
+  }
+}
+
+void
+test_unit(void)
+{
+  char conf[][100] = {
+"leapsectz right/UTC",
+"leapseclist /usr/share/zoneinfo/leap-seconds.list"
+  };
+
+  CNF_Initialise(0, 0);
+  for (int i = 0; i < sizeof conf / sizeof conf[0]; i++)
+CNF_ParseLine(NULL, i + 1, conf[i]);
+  LDB_Initialise();
+
+  DEBUG_LOG("testing get_tz_leap");
+  test_leap_source(get_tz_leap);
+
+  DEBUG_LOG("testing get_leap_sec_list_leap");
+  test_leap_source(get_leap_sec_list_leap);
+
+  /* This exercises the twice-per-day logic */
+  DEBUG_LOG("testing LDB_GetLeap");
+  test_leap_source(LDB_GetLeap);
+
+  LDB_Finalise();
+  CNF_Finalise();
+}
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v3 4/5] leapdb: support leap-seconds.list as second source

[patrick . oppenlander]

+
+/* Offset between leap-seconds.list timestamp epoch and Unix epoch.
+   leap-seconds.list epoch is 1 Jan 1900, 00:00:00 */
+static const long long LEAP_SEC_LIST_OFFSET = 2208988800;
 
 /* == */
 
@@ -59,7 +68,7 @@ get_tz_leap(time_t when, int *tai_offset)
   return tz_leap;
 strcpy(tz_orig, tz_env);
   }
-  setenv("TZ", leap_tzname, 1);
+  setenv("TZ", CNF_GetLeapSecTimezone(), 1);
   tzset();
 
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
@@ -93,6 +102,78 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
+static NTP_Leap
+get_leap_sec_list_leap(time_t when, int *tai_offset)
+{
+  FILE *f;
+  char *line = NULL;
+  size_t linelen = 0;
+  NTP_Leap lsl_leap = LEAP_Normal;
+  int prev_lsl_tai_offset = 10;
+  long long lsl_updated = 0, lsl_expiry = 0;
+
+  if (!(f = fopen(CNF_GetLeapSecList(), "r"))) {
+LOG(LOGS_ERR, "Failed to open leap seconds list %s", CNF_GetLeapSecList());
+goto out;
+  }
+
+  /* Leap second happens at midnight */
+  when = (when / (24 * 3600) + 1) * (24 * 3600);
+
+  /* leap-seconds.list timestamps are relative to 1 Jan 1900, 00:00:00 */
+  when += LEAP_SEC_LIST_OFFSET;
+
+  while (getline(&line, &linelen, f) > 0) {
+long long lsl_when;
+int lsl_tai_offset;
+
+if (*line == '#') {
+  /* Update time line starts with #$ */
+  if (line[1] == '$' && sscanf(line + 2, "%lld", &lsl_updated) != 1)
+goto error;
+  /* Expiration time line starts with #@ */
+  if (line[1] == '@' && sscanf(line + 2, "%lld", &lsl_expiry) != 1)
+goto error;
+  /* Comment or a special comment we don't care about */
+  continue;
+}
+
+/* Leap entry */
+if (sscanf(line, "%lld %d", &lsl_when, &lsl_tai_offset) != 2)
+  goto error;
+
+if (when == lsl_when) {
+  if (lsl_tai_offset > prev_lsl_tai_offset)
+lsl_leap = LEAP_InsertSecond;
+  else if (lsl_tai_offset < prev_lsl_tai_offset)
+lsl_leap = LEAP_DeleteSecond;
+  /* When is rounded to the end of the day, so offset hasn't changed yet! 
*/
+  *tai_offset = prev_lsl_tai_offset;
+} else if (when > lsl_when)
+  *tai_offset = lsl_tai_offset;
+
+prev_lsl_tai_offset = lsl_tai_offset;
+  }
+
+  /* Make sure the file looks sensible */
+  if (!feof(f) || !lsl_updated || !lsl_expiry)
+goto error;
+
+  if (when >= lsl_expiry)
+LOG(LOGS_WARN, "Leap second list %s needs update", CNF_GetLeapSecList());
+
+  goto out;
+
+error:
+  LOG(LOGS_ERR, "Failed to parse leap seconds list %s", CNF_GetLeapSecList());
+out:
+  if (f)
+fclose(f);
+  return lsl_leap;
+}
+
+/* == */
+
 static int
 check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
@@ -111,14 +192,30 @@ check_leap_source(NTP_Leap (*src)(time_t when, int 
*tai_offset))
 void
 LDB_Initialise(void)
 {
-  leap_tzname = CNF_GetLeapSecTimezone();
+  const char *leap_tzname = CNF_GetLeapSecTimezone();
   if (leap_tzname && !check_leap_source(get_tz_leap)) {
 LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
 leap_tzname = NULL;
   }
 
-  if (leap_tzname)
+  const char *leap_sec_list = CNF_GetLeapSecList();
+  if (leap_sec_list && !check_leap_source(get_leap_sec_list_leap)) {
+LOG(LOGS_WARN, "Leap second list %s failed check, ignoring", 
leap_sec_list);
+leap_sec_list = NULL;
+  }
+
+  if (leap_sec_list && leap_tzname) {
+LOG(LOGS_WARN, "Multiple leap second sources, ignoring leapsectz");
+leap_tzname = NULL;
+  }
+
+  if (leap_sec_list) {
+LOG(LOGS_INFO, "Using leap second list %s", leap_sec_list);
+leap_src = SRC_LEAP_SEC_LIST;
+  } else if (leap_tzname) {
 LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
+leap_src = SRC_TZ;
+  }
 }
 
 /* == */
@@ -139,8 +236,16 @@ LDB_GetLeap(time_t when, int *tai_offset)
   ldb_leap = LEAP_Normal;
   ldb_tai_offset = 0;
 
-  if (leap_tzname)
+  switch (leap_src) {
+  case SRC_NONE:
+break;
+  case SRC_TZ:
 ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+break;
+  case SRC_LEAP_SEC_LIST:
+ldb_leap = get_leap_sec_list_leap(when, &ldb_tai_offset);
+break;
+  }
 
 out:
   *tai_offset = ldb_tai_offset;
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v3 3/5] leapdb: move source check into separate function

[patrick . oppenlander]

From: Patrick Oppenlander 

The sanity checks are valid for all possible sources of leap second
information, so move them into a separate function check_leap_source().
---
 leapdb.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 32f753a..c8a42cb 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -93,22 +93,32 @@ get_tz_leap(time_t when, int *tai_offset)
 
 /* == */
 
-void
-LDB_Initialise(void)
+static int
+check_leap_source(NTP_Leap (*src)(time_t when, int *tai_offset))
 {
   int tai_offset;
 
+  /* Check that the leap second source has good data for Jun 30 2012 and Dec 
31 2012 */
+  if (src(1341014400, &tai_offset) == LEAP_InsertSecond && tai_offset == 34 &&
+  src(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 35)
+return 1;
+
+  return 0;
+}
+
+/* == */
+
+void
+LDB_Initialise(void)
+{
   leap_tzname = CNF_GetLeapSecTimezone();
-  if (leap_tzname) {
-/* Check that the timezone has good data for Jun 30 2012 and Dec 31 2012 */
-if (get_tz_leap(1341014400, &tai_offset) == LEAP_InsertSecond && 
tai_offset == 34 &&
-get_tz_leap(1356912000, &tai_offset) == LEAP_Normal && tai_offset == 
35) {
-  LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
-} else {
-  LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
-  leap_tzname = NULL;
-}
+  if (leap_tzname && !check_leap_source(get_tz_leap)) {
+LOG(LOGS_WARN, "Timezone %s failed leap second check, ignoring", 
leap_tzname);
+leap_tzname = NULL;
   }
+
+  if (leap_tzname)
+LOG(LOGS_INFO, "Using %s timezone to obtain leap second data", 
leap_tzname);
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-dev] [PATCH v3 2/5] leapdb: make twice per day check logic common

[patrick . oppenlander]

From: Patrick Oppenlander 

We want to do the twice per day check regardless of the data source.
Move the check up one level from get_tz_leap() into LDB_GetLeap().
---
 leapdb.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/leapdb.c b/leapdb.c
index 676a0d5..32f753a 100644
--- a/leapdb.c
+++ b/leapdb.c
@@ -41,24 +41,10 @@ static char *leap_tzname;
 static NTP_Leap
 get_tz_leap(time_t when, int *tai_offset)
 {
-  static time_t last_tz_leap_check;
-  static NTP_Leap tz_leap;
-  static int tz_tai_offset;
-
   struct tm stm, *tm;
   time_t t;
   char *tz_env, tz_orig[128];
-
-  *tai_offset = tz_tai_offset;
-
-  /* Do this check at most twice a day */
-  when = when / (12 * 3600) * (12 * 3600);
-  if (last_tz_leap_check == when)
-  return tz_leap;
-
-  last_tz_leap_check = when;
-  tz_leap = LEAP_Normal;
-  tz_tai_offset = 0;
+  NTP_Leap tz_leap = LEAP_Normal;
 
   tm = gmtime(&when);
   if (!tm)
@@ -79,7 +65,7 @@ get_tz_leap(time_t when, int *tai_offset)
   /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */
   t = mktime(&stm);
   if (t != -1)
-tz_tai_offset = t - when + 10;
+*tai_offset = t - when + 10;
 
   /* Set the time to 23:59:60 and see how it overflows in mktime() */
   stm.tm_sec = 60;
@@ -102,8 +88,6 @@ get_tz_leap(time_t when, int *tai_offset)
   else if (stm.tm_sec == 1)
 tz_leap = LEAP_DeleteSecond;
 
-  *tai_offset = tz_tai_offset;
-
   return tz_leap;
 }
 
@@ -132,10 +116,25 @@ LDB_Initialise(void)
 NTP_Leap
 LDB_GetLeap(time_t when, int *tai_offset)
 {
-  *tai_offset = 0;
+  static time_t last_ldb_leap_check;
+  static NTP_Leap ldb_leap;
+  static int ldb_tai_offset;
+
+  /* Do this check at most twice a day */
+  when = when / (12 * 3600) * (12 * 3600);
+  if (last_ldb_leap_check == when)
+goto out;
+
+  last_ldb_leap_check = when;
+  ldb_leap = LEAP_Normal;
+  ldb_tai_offset = 0;
+
   if (leap_tzname)
-return get_tz_leap(when, tai_offset);
-  return LEAP_Normal;
+ldb_leap = get_tz_leap(when, &ldb_tai_offset);
+
+out:
+  *tai_offset = ldb_tai_offset;
+  return ldb_leap;
 }
 
 /* == */
-- 
2.43.0


-- 
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.