https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283550
Bug ID: 283550
Summary: freebsd-update doesn't refresh leapsecond file
Product: Base System
Version: 13.4-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: b...@freebsd.org
Reporter: v...@f-m.fm
This issue was encountered on 13.{1,2,3,4}-RELEASE. Other releases not tested.
A 13.1-p3 amd64 bhyve guest instance needed to be upgraded to latest 13.4. This
was done stepwise, merging files when prompted. The guest instance is an
uncomplicated config - a simple web server. The OS has always been maintained
with freebsd-update.
the path to 13.4-p1 from 13.1-p3 was conducted stepwise
latest 13.1 => latest 13.2 => latest 13.3 => latest 13.4
I thought a straight upgrade 13.1 => 13.4 might be too big a jump.
I was surprised to find that at each stage in the upgrade, ntpd showed in the
console at bootup that the leapsecond file was out of date. Example output:
Dec 23 16:00:21 REDACTED ntpd[604]: leapsecond file
(‘/var/db/ntpd.leap-seconds.list’): expired 362 days ago
This is from the fully upgraded (so, 13.4-p1) system
in /etc/rc.conf there's the following ntp-related settings
ntpdate_enable="YES"
ntpd_enable="YES"
In /etc/defaults/rc.conf there's the following ntpd variables pertaining to
leapseconds
ntpd_flags="" # Additional flags to ntpd
ntp_src_leapfile="/etc/ntp/leap-seconds"
# Initial source for ntpd leapfile
ntp_db_leapfile="/var/db/ntpd.leap-seconds.list"
ntp_leapfile_sources="https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
https://data.iana.org/time-zones/tzdb/leap-seconds.list";
ntp_leapfile_fetch_opts="-mq" # Options to use for ntp leapfile fetch,
ntp_leapfile_expiry_days=30 # Check for new leapfile 30 days prior to
ntp_leapfile_fetch_verbose="NO" # Be verbose during NTP leapfile fetch
--
You are receiving this mail because:
You are the assignee for the bug.
