Timezone problems on -current

[bob prohaska]

It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the
machine reports a local time of
***@nemesis:~ % date
Mon May 3 15:27:04 PDT 2021
while a Pi2 reports
***@www:~ % date
Mon May 3 08:28:35 PDT 2021

The timezone is PDT in both cases, but the time shown looks like
UTC for the Pi4 but PDT for the Pi2.

I've noticed this before and cured it for a while by running tzsetup.
The problem seems to return each time the OS is upgraded, though I
have not kept careful track of what's going on. Anybody else noticed
this?

Thanks for reading,

bob prohaska

[Valery Seys]

Post by bob prohaska
It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the
machine reports a local time of
Mon May 3 15:27:04 PDT 2021
while a Pi2 reports
Mon May 3 08:28:35 PDT 2021
The timezone is PDT in both cases, but the time shown looks like
UTC for the Pi4 but PDT for the Pi2.
I've noticed this before and cured it for a while by running tzsetup.
The problem seems to return each time the OS is upgraded, though I
have not kept careful track of what's going on. Anybody else noticed
this?
Thanks for reading,
bob prohaska
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arm

1. instead of using 'tzsetup', copy your
/usr/share/zoneinfo/<location>/localtime to /etc/localtime
2. then, see if the upgrade remove/overwrite it

It's weird 'date' report PDT in both case. Have you any 'TZ' var. set in your
environ ? Try unset it, then 'date' should show the UTC. In short, I think TZ
must be set accordingly to /etc/localtime in order to show something coherent.

My 2 cents,

p&l

v/

[Mark Millard via freebsd-arm]

Post by bob prohaska
It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the
machine reports a local time of
Mon May 3 15:27:04 PDT 2021
while a Pi2 reports
Mon May 3 08:28:35 PDT 2021
The timezone is PDT in both cases, but the time shown looks like
UTC for the Pi4 but PDT for the Pi2.

Note: I assume that neither RPi* has a RTC, not that
it makes much of a difference here.

I expect that one RPi* has a file:

# ls -Tld /etc/wall_cmos_clock
-r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock

and the other does not.

QUOTE ( from https://www.freebsd.org/cgi/man.cgi?adjkerntz(8) )
. . .
. . . If the file /etc/wall_cmos_clock exists, it means
that the CMOS clock keeps local time (MS-DOS and MS-Windows compatible
mode). If that file does not exist, it means that the CMOS clock keeps
UTC time.
. . .
/etc/wall_cmos_clock Empty file. Its presence indicates that the ma-
chine's CMOS clock is set to local time, while its
absence indicates a UTC CMOS clock.
END QUOTE

However, it has an effect on time handling even when
no RTC (no CMOS clock) is present.

If you want times to look right on ms-dos and Windows for the
msdos file system involved, you then want to boot and
synchronize time with /etc/wall_cmos_clock present.

Otherwise you likely do not want /etc/wall_cmos_clock present
for such activities.

If you want times to closely agree, all RPi*'s should have the
same /etc/wall_cmos_clock status, which ever way you go.

There can be an issue of time going backwards, depending on
the delete vs. add action for /etc/wall_cmos_clock .

Post by bob prohaska
I've noticed this before and cured it for a while by running tzsetup.
The problem seems to return each time the OS is upgraded, though I
have not kept careful track of what's going on. Anybody else noticed
this?

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[bob prohaska]

Post by Mark Millard via freebsd-arm

Post by bob prohaska
It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the
machine reports a local time of
Mon May 3 15:27:04 PDT 2021
while a Pi2 reports
Mon May 3 08:28:35 PDT 2021
The timezone is PDT in both cases, but the time shown looks like
UTC for the Pi4 but PDT for the Pi2.

Note: I assume that neither RPi* has a RTC, not that
it makes much of a difference here.

Correct, no RTC on any of them.

Post by Mark Millard via freebsd-arm
# ls -Tld /etc/wall_cmos_clock
-r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock
and the other does not.

All RPi*s in my collection report having /etc/wall_cmos_clock,
including the one displaying the wrong time. Some are Pi2, running
armv7 12.2-stable, two are Pi3 running 14-current and 13.0-stable.
The only one showing wrong time is the Pi4 running 14-current.

When the Pi4 finishes building www/chromium I'll start experimenting
to identify just what I did to get the clock wrong. The obvious test
would be to correct the time with tzsetup and then update world and
kernel, reboot and see if time is again wrong. If there are other,
better things to try please indicate. I've never seen timekeeping
problems and know nothing of how it's done.

This begs a question: If I simply re-run installworld, without updating,
will it overwrite the existing world again without rebuilding everything?
That would speed up the experiment considerably.

Post by Mark Millard via freebsd-arm
There can be an issue of time going backwards, depending on
the delete vs. add action for /etc/wall_cmos_clock .

I've long wondered about messing with time settings while the
machine is doing something important, like running make. Is that
something to avoid?

Thanks for writing!

bob prohaska

[Mark Millard via freebsd-arm]

Post by bob prohaska

Post by Mark Millard via freebsd-arm

Post by bob prohaska
It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the
machine reports a local time of
Mon May 3 15:27:04 PDT 2021
while a Pi2 reports
Mon May 3 08:28:35 PDT 2021
The timezone is PDT in both cases, but the time shown looks like
UTC for the Pi4 but PDT for the Pi2.

Note: I assume that neither RPi* has a RTC, not that
it makes much of a difference here.

Correct, no RTC on any of them.

Post by Mark Millard via freebsd-arm
# ls -Tld /etc/wall_cmos_clock
-r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock
and the other does not.

All RPi*s in my collection report having /etc/wall_cmos_clock,
including the one displaying the wrong time.

So much for my expectations.

Post by bob prohaska
Some are Pi2, running
armv7 12.2-stable, two are Pi3 running 14-current and 13.0-stable.
The only one showing wrong time is the Pi4 running 14-current.

Do all the RPi*'s agree for there output for:

# sysctl machdep.adjkerntz
machdep.adjkerntz: 0

?

(My example context; yours may vary. But to get uniform
handling, you would want all yours to agree.)

Do all the RPi*'s agree for their output of:

# strings /etc/localtime | tail -1
PST8PDT,M3.2.0,M11.1.0

(My example context; yours may vary. But to get uniform
handling, you would want all yours to agree.)

I'll note that:

# strings /etc/localtime | head -1
TZif2

indicates the format-version of the file from
what I can tell, allowing some cross checking
for things being as expected.

"man adjkerntz" has information on the subject.

Post by bob prohaska
When the Pi4 finishes building www/chromium I'll start experimenting
to identify just what I did to get the clock wrong. The obvious test
would be to correct the time with tzsetup and then update world and
kernel, reboot and see if time is again wrong. If there are other,
better things to try please indicate. I've never seen timekeeping
problems and know nothing of how it's done.

I'm not so sure that this large-change would well isolate
the problem --or be likely to change anything.

Post by bob prohaska
This begs a question: If I simply re-run installworld, without updating,
will it overwrite the existing world again without rebuilding everything?

If you avoid buildworld and just installworld, sure.
(buildworld after installworld will rebuild various
things because of changes installworld makes, based
on what META_MODE tests for.)

But I'm not sure why you would do this. I'll note
that there are other targets for installing some
types of files, but they tend to destroy local tailoring
and so are normally only for starting over. Otherwise
etcupdate or the like deals with file adjustments
in a way less likely to replace your localizations.

Post by bob prohaska
That would speed up the experiment considerably.

Post by Mark Millard via freebsd-arm
There can be an issue of time going backwards, depending on
the delete vs. add action for /etc/wall_cmos_clock .

I've long wondered about messing with time settings while the
machine is doing something important, like running make. Is that
something to avoid?

Yep: avoid time changes in the middle of other things
that are based on comparing timestamps. make, in part,
uses timestamp comparisons. If date output ends up
before file system dates, waiting for the correct
time order can be appropriate.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[bob prohaska]

It looks like the culprit might be ntpdate not running when it should.
When ntpdate runs towards the end of boot it reports what it did. In
/var/run/dmesg.boot there's no output from the last boot. I've seen
output from it before, so at least sometimes it works, but apparently
not always.

Sorry for the noise!

bob prohaska

[tech-lists]

Hi,

Post by bob prohaska
It seems that the timezone gets screwed up each time the OS is
upgraded on a Pi4 via sources on -current. ntpdate is working, but the

[snip]

On all my VMs which are mostly 12.2-p6/amd64 I run ntpdate and ntpd
and they'll all return a line like this:

ntpdate[532]: step time server 178.79.145.244 offset -3598.919836 sec

when rebooted. I have this in my /etc/rc.conf:

# ntpd
ntpdate_enable="YES"
ntpdate_flags="-b"
ntpdate_hosts="uk.pool.ntp.org"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

if those lines are missing, the clock will show a majorly drifted value
on reboot, and unless ntpd is told to, it won't set the proper time
immediately. It'll do it in small increments over a long time. With my
config, when login appears, the time is correctly set. Maybe it doesn't
need the ntpdate lines. I understand that ntpdate is being phased out?
Anyway, it seems to work, for now.

[bob prohaska]

Post by tech-lists
# ntpd
ntpdate_enable="YES"
ntpdate_flags="-b"
ntpdate_hosts="uk.pool.ntp.org"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most
obvious suspect is a wireless ethernet bridge that might be saying
it's up before the access point is responsive.

I'll have to do a few test reboots when the machine becomes idle.
I know ntpdate works sometimes, but perhaps not always.

Thanks for writing,

bob prohaska

[Mark Millard via freebsd-arm]

Post by bob prohaska

Post by tech-lists
# ntpd
ntpdate_enable="YES"
ntpdate_flags="-b"
ntpdate_hosts="uk.pool.ntp.org"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

Warning from the ntpdate man page:

QUOTE
The ntpdate utility will decline to set the date if an NTP server daemon
(e.g., ntpd(8)) is running on the same host.
END QUOTE

The above enables both and possibly makes the two
compete with each other depending on how they race
at the start. I'd avoid the mix.

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most
obvious suspect is a wireless ethernet bridge that might be saying
it's up before the access point is responsive.
I'll have to do a few test reboots when the machine becomes idle.
I know ntpdate works sometimes, but perhaps not always.

I'll note that I use ntpd instead of ntpdate in
my /etc/rc.conf files:

ntpd_enable="YES"
ntpd_sync_on_start="YES"
ntpd_user="root"

Such might be an alternative. But I do not know the
detailed tradeoffs for this or other alternatives.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by bob prohaska

Post by tech-lists
# ntpd
ntpdate_enable="YES"
ntpdate_flags="-b"
ntpdate_hosts="uk.pool.ntp.org"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

QUOTE
The ntpdate utility will decline to set the date if an NTP server daemon
(e.g., ntpd(8)) is running on the same host.
END QUOTE
The above enables both and possibly makes the two
compete with each other depending on how they race
at the start. I'd avoid the mix.

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most
obvious suspect is a wireless ethernet bridge that might be saying
it's up before the access point is responsive.
I'll have to do a few test reboots when the machine becomes idle.
I know ntpdate works sometimes, but perhaps not always.

I'll note that I use ntpd instead of ntpdate in
ntpd_enable="YES"
ntpd_sync_on_start="YES"
ntpd_user="root"
Such might be an alternative. But I do not know the
detailed tradeoffs for this or other alternatives.

Another quote from "man ntpdate":

QUOTE
Note: The functionality of this program is now available in the ntpd(8)
program. See the -q command line option in the ntpd(8) page. After a
suitable period of mourning, the ntpdate utility is to be retired from
this distribution.
END QUOTE


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[tech-lists]

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"

Seems ntpdate isn't required if these are set in /etc/rc.conf

ntpd_enable="YES"
ntpd_sync_on_start="YES"

even on boards with no RTC.

[bob prohaska]

Post by tech-lists

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"

Seems ntpdate isn't required if these are set in /etc/rc.conf
ntpd_enable="YES"
ntpd_sync_on_start="YES"
even on boards with no RTC.

Indeed it looks as if ntpdate is going away, replaced by
enhancements to ntpd.

Still, I think the timekeeping errors are caused by a somewhat
unconventional network setup on the machine having problems.
The rest of the hosts in my "data center" use ntpdate and
have no trouble keeping their clocks right, but those hosts
all have wired ethernet. The host with the wrong clock setting
uses an ethernet-to-wifi adapter. Can't be sure until more
testing is done. And, I might be wrong again.....

Thanks for writing,

bob prohaska

[Paul Mather]

Post by bob prohaska

Post by tech-lists

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"

Seems ntpdate isn't required if these are set in /etc/rc.conf
ntpd_enable="YES"
ntpd_sync_on_start="YES"
even on boards with no RTC.

Indeed it looks as if ntpdate is going away, replaced by
enhancements to ntpd.
Still, I think the timekeeping errors are caused by a somewhat
unconventional network setup on the machine having problems.
The rest of the hosts in my "data center" use ntpdate and
have no trouble keeping their clocks right, but those hosts
all have wired ethernet. The host with the wrong clock setting
uses an ethernet-to-wifi adapter. Can't be sure until more
testing is done. And, I might be wrong again.....

The problem with ntpdate is that it is a one-time clock adjustment whereas ntpd is a continuous time monitoring/adjustment. So, if your system has problems with clock drift or just keeping accurate time, ntpdate run on boot will not help in the long term. Ntpd, on the other hand, will.

Note also that 'ntpd_sync_on_start="YES"' is effectively the same as running ntpddate. The 'ntpd_sync_on_start="YES"' setting lets ntpd perform a one-time large step time adjustment (via the "-g" option), which is essentially what you are achieving when running ntpdate. Normally, ntpd will baulk if the clock is off by 1000s, which can easily happen with systems that have no RTC, hence the need for the 'ntpd_sync_on_start="YES"' flag.

When I ran FreeBSD/arm, I used the net/ntimed port to maintain time, which is a simple, low-resource alternative to ntpd for keeping time on FreeBSD/arm clients.

Cheers,

Paul.

[Ian Lepore]

Post by bob prohaska

Post by tech-lists
# ntpd
ntpdate_enable="YES"
ntpdate_flags="-b"
ntpdate_hosts="uk.pool.ntp.org"
ntpd_enable="YES"
ntpd_sync_on_start="YES"

Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most
obvious suspect is a wireless ethernet bridge that might be saying
it's up before the access point is responsive.
I'll have to do a few test reboots when the machine becomes idle.
I know ntpdate works sometimes, but perhaps not always.
Thanks for writing,
bob prohaska

You don't need to be running ntpdate at all. ntpd_sync_on_start gives
you the same effect... it allows ntpd to step the clock any required
amount, one time at startup. It's useful for systems that don't have a
battery-backed clock.

I like to set kern.timecounter.stepwarnings=1 in /etc/sysctl.conf so I
have a record in syslog of when ntpd steps the clock.

-- Ian

[bob prohaska]

Post by Ian Lepore

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most

You don't need to be running ntpdate at all. ntpd_sync_on_start gives
you the same effect... it allows ntpd to step the clock any required
amount, one time at startup. It's useful for systems that don't have a
battery-backed clock.

It seems clear that ntpd_sync_on_start is a better choice than ntpdate.
Clock drift on the Pi seems fairly slow, a couple seconds a month, but
staying right on can't hurt and doesn't cost much.

Post by Ian Lepore
I like to set kern.timecounter.stepwarnings=1 in /etc/sysctl.conf so I
have a record in syslog of when ntpd steps the clock.

Most of my trouble seems to have been caused by timesetting not running at
startup and me not noticing promptly. A combination of ntpd_sync_on_start
and a -g flag will set the clock and make a fuss in the logfiles if
time drifts too far off. Is there a way to make a fuss if ntpd fails
to start in the first place or quits in mid-flight?

Thanks for writing!

bob prohaska

[Ian Lepore]

Post by bob prohaska

Post by Ian Lepore

Post by bob prohaska
Up to now I've used only the line
ntpdate_enable="YES"
and it's been enough to keep the clock sane. On the last reboot
it appears ntpdate either didn't run or failed silently. The most

You don't need to be running ntpdate at all. ntpd_sync_on_start gives
you the same effect... it allows ntpd to step the clock any
required
amount, one time at startup. It's useful for systems that don't have a
battery-backed clock.

It seems clear that ntpd_sync_on_start is a better choice than
ntpdate.
Clock drift on the Pi seems fairly slow, a couple seconds a month, but
staying right on can't hurt and doesn't cost much.

Post by Ian Lepore
I like to set kern.timecounter.stepwarnings=1 in /etc/sysctl.conf so I
have a record in syslog of when ntpd steps the clock.

Most of my trouble seems to have been caused by timesetting not running at
startup and me not noticing promptly. A combination of
ntpd_sync_on_start
and a -g flag will set the clock and make a fuss in the logfiles if
time drifts too far off. Is there a way to make a fuss if ntpd fails
to start in the first place or quits in mid-flight?
Thanks for writing!
bob prohaska

Setting ntpd_sync_on_start=yes sets the -g flag for you, you don't also
have to set ntpd_flags yourself.

-- Ian