Time Is UTC, but Time Zone Is Local

Scribner · Nov 23, 2021

After my second install of FreeBSD last week, I am confused as to the best way to go about fixing my system's defective clock. I thought I set up FreeBSD correctly, yet whenever the computer boots up it shows UTC as the time, but shows my time zone as "CST" (UTC-6). The time is also always more than a minute slow for UTC, yet ntpd_enable="YES" is enabled in /etc/rc.conf (I enabled ntpd during installation).

This thread from more than 10 years ago seems to discuss perhaps the same problem. But the answers are varied: running # touch /etc/wall_cmos_clock, running # date, running tzsetup(1), etc. I'm just a newbie, but it seems like there should be just one best way to fix this problem. Yesterday, in another one of my threads, a user said to run # date.

Does anyone know the best way to fix this issue?

VladiBG · Nov 23, 2021

The easy way is to run bsdconfig select timezone and set your CMOS to local time this will create for you the empty file /etc/wall_cmos_clock as it's indicated in adjkerntz(8)

Or use tzsetup(8) to set your desire timezone and then use ntpdate(8) to set your clock via the ntp server.

Alain De Vos · Nov 24, 2021

Also verify if /etc/localtime is a softlink to /usr/share/zoneinfo/X/Y

SirDice · Nov 24, 2021

Alain De Vos said:
Also verify if /etc/localtime is a softlink to /usr/share/zoneinfo/X/Y

It's a hardlink, not a softlink.

covacat · Nov 24, 2021

SirDice said:
It's a hardlink, not a softlink.

unless /usr is on its own fs ?
for me its just a regular file with no links

SirDice · Nov 24, 2021

covacat said:
for me its just a regular file with no links

I could have sworn this used to be a hardlink, but you're right, it's a copy.

Code:

root@molly:~ # ls -li /etc/localtime /usr/share/zoneinfo/Europe/Amsterdam
229493 -r--r--r--  1 root  wheel  2923 Nov 24 11:45 /etc/localtime
 52929 -r--r--r--  1 root  wheel  2923 Nov 22 18:02 /usr/share/zoneinfo/Europe/Amsterdam

covacat · Nov 24, 2021

until zfs on root became a thing /usr default was on rootdisk0s1e so diff fs then /etc. it may still be for mbr/ufs installs

SirDice · Nov 24, 2021

covacat said:
until zfs on root became a thing /usr default was on rootdisk0s1e so diff fs then /etc. it may still be for mbr/ufs installs

Yes, the old-school install used separate filesystems for /usr, /var and /tmp. Not the case any more though, an automatic MBR/UFS install will just create one large root filesystem.

VladiBG · Nov 24, 2021

The zone file is installed via f_install_zoneinfo_file() function and if you read the code you will see that it may be a copy of the file using "cat" when copymode is true or softlink when copymode is false.

copymode value is set based on the following test of "-L file exist and it's symbolic link" using

Code:

_PATH_LOCALTIME="/etc/localtime"

if [ -L "$_PATH_LOCALTIME" ]; then
        copymode=
    elif [ ! -e "$_PATH_LOCALTIME" ]; then
        # Nothing there yet...
        copymode=1
    else
        copymode=1
    fi

freebsd-src/usr.sbin/bsdconfig/timezone/share/zones.subr at main · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

Code:

    if [ "$copymode" ]; then
        f_eval_catch $catch_args $funcname rm \
            'rm -f "%s"' "$_PATH_LOCALTIME" || return $FAILURE
        f_eval_catch $catch_args $funcname sh \
            'umask 222 && :> "%s"' "$_PATH_LOCALTIME" ||
            return $FAILURE
        f_eval_catch $catch_args $funcname sh \
            'cat "%s" > "%s"' \
            "$zoneinfo_file" "$_PATH_LOCALTIME" || return $FAILURE
    else
        f_eval_catch $catch_args $funcname sh \
            '( :< "%s" )' "$zoneinfo_file" || return $FAILURE
        f_eval_catch $catch_args $funcname rm \
            'rm -f "%s"' "$_PATH_LOCALTIME" || return $FAILURE
        f_eval_catch $catch_args $funcname ln \
            'ln -s "%s" "%s"' \
            "$zoneinfo_file" "$_PATH_LOCALTIME" || return $FAILURE
    fi # copymode

Scribner · Nov 24, 2021

I'm glad this thread sprouted out a discussion of (what I believe is) a related issue, but it seems my original post only garnered one solution, the first reply:

VladiBG said:
The easy way is to run bsdconfig select timezone and set your CMOS to local time this will create for you the empty file /etc/wall_cmos_clock as it's indicated in adjkerntz(8)

Or if you prefer the manual way create that file then use tzsetup(8) to set your desire timezone and then use ntpdate(8) to set your clock via the ntp server.

This is also a new solution that is not mentioned in the older thread. Therefore, I am seeking out more advice and/or confirmation to use this method. I looked at the man page for bsdconfig, and it seems applicable. If I use this option, should I run bsdconfig as root?

SirDice · Nov 24, 2021

Just use tzsetup(8). No need to create that file, tzsetup(8) is going to ask if your clock is on UTC or not and set it accordingly. If you dual boot with Windows, don't set it to UTC. Or modify a Windows registry setting if you really want to use UTC. Windows assumes your CMOS clock is running local time by default.

Scribner said:
If I use this option, should I run bsdconfig as root?

Yes. Or else it won't be able to make the necessary changes.

Note that this will only fix the timezone issues you're having. It won't do anything for the apparent clock drift your system has. Older systems can have this. The only solution to that is to run ntpd(8) (or some other NTP daemon, like OpenNTPD).

VladiBG · Nov 24, 2021

Scribner said:
should I run bsdconfig as root?

Yes you have to run it as root. If you try to run it as normal non privileged user you will get error message. But instead of asking just do it you can't go wrong.

Scribner · Nov 24, 2021

SirDice said:
Just use tzsetup(8). No need to create that file, tzsetup(8) is going to ask if your clock is on UTC or not and set it accordingly. If you dual boot with Windows, don't set it to UTC. Or modify a Windows registry setting if you really want to use UTC. Windows assumes your CMOS clock is running local time by default.

Yes. Or else it won't be able to make the necessary changes.

Note that this will only fix the timezone issues you're having. It won't do anything for the apparent clock drift your system has. Older systems can have this. The only solution to that is to run ntpd(8) (or some other NTP daemon, like OpenNTPD).

I looked at the man page for tzsetup(8). So you are saying to just run the tzsetup utility as root? Like this: # tzsetup?

Keep in mind, it does appear my time zone is set correctly to CST (UTC-6). But it sounds like tzsetup is going to ask if my clock is on UTC, in which case I should answer... what? I'm sorry if that sounds like a dumb question; it's just that I thought I was asked it (or something similar) during the installation, and I wasn't sure how to answer it (I went with what the installer and/or the Handbook recommended).

Edit: I just read your note at the bottom. My system is just a couple years old. In my original post I say ntpd_enable="YES" is enabled. So would running ntpd(8) do anything?

SirDice · Nov 24, 2021

Scribner said:
I'm sorry if that sounds like a dumb question; it's just that I thought I was asked it (or something similar) during the installation, and I wasn't sure how to answer it (I went with what the installer and/or the Handbook recommended).

Read the actual question, "If it's set to local time, or you don't know, choose NO". You don't know, so pick NO. Leaving your CMOS clock on local time (not UTC) is the safest option. If you don't dual boot with another OS it's not going to matter if your CMOS clock is running UTC or local time anyway.

eternal_noob · Nov 24, 2021

VladiBG said:
But instead of asking just do it you can't go wrong.

If you read his other thread, you'll get that he wants to know every little detail before doing anything.

Scribner · Nov 24, 2021

SirDice said:
Read the actual question, "If it's set to local time, or you don't know, choose NO". You don't know, so pick NO. Leaving your CMOS clock on local time (not UTC) is the safest option. If you don't dual boot with another OS it's not going to matter if your CMOS clock is running UTC or local time anyway.

I just ran # tzsetup (as root), and selected NO for the first question, but the clock is still set to UTC. This is also what I did when I installed FreeBSD.

I am not dual booting with another OS.

A related question: Do you know why tzsetup(8) was still on the screen after I answered the last question (confirming that the time zone abbreviation looked reasonable)? So there was still that blue screen with the command prompt in black and white at the bottom.

I don't know anything about Unix, but do you think, since it's possible ntpd isn't working at boot time (because of the apparent clock drift), running ntpd(8) will solve both the time being off by six hours (UTC) and over a minute (clock drift)? If so, do I just need to run # ntpd (as root)?

SirDice · Nov 24, 2021

Scribner said:
but the clock is still set to UTC.

Did you select the right timezone after that question?

Scribner said:
A related question: Do you know why tzsetup(8) was still on the screen after I answered the last question (confirming that the time zone abbreviation looked reasonable)? So there was still that blue screen with the command prompt in black and white at the bottom.

It's a text based selection. It's just text that's printed to the TTY, it doesn't clear the screen after you exit it. I mean the output from ls(1) stays on the screen too after you entered that command.

Scribner said:
I don't know anything about Unix, but, do you think since it's possible ntpd isn't working at boot time (because of the apparent clock drift), running ntpd(8) will solve both the time being off by six hours (UTC) and over a minute (clock drift)?

If the difference is too big ntpd(8) won't change the time, that's a safety precaution. You can add ntpd_sync_on_start="YES" to rc.conf to just force to set it, regardless of the time difference.

Scribner said:
If so, do I just need to run # ntpd (as root)?

It's a daemon, or service, it runs in the background. You enable it; sysrc ntpd_enable="YES" then start it service ntpd start (After making sure /etc/ntp.conf is set correctly).

Scribner · Nov 24, 2021

SirDice said:
Did you select the right timezone after that question?

Yes, the time zone is set to CST for United States of America -> Central (most states).

VladiBG · Nov 24, 2021

what is the output of service ntpd status

Scribner · Nov 24, 2021

VladiBG said:
what is the output of service ntpd status

I ran that command as a regular user (not root):

% service ntpd status
returned
ntpd is not running.

VladiBG · Nov 24, 2021

Good then you can use ntpdate 0.freebsd.pool.ntp.org to set up your clock. (must be run as root)
And if you want periodical checks you can enable ntpd using sysrc ntpd_enable=YES and then service ntpd start the ntpd will take care of your clock synchronization.

Scribner · Nov 24, 2021

VladiBG said:
Good then you can use ntpdate 0.freebsd.pool.ntp.org to set up your clock. (must be run as root)
And if you want periodical checks you can enable ntpd using sysrc ntpd_enable=YES and then service ntpd start the ntpd will take care of your clock synchronization.

Shouldn't it have returned that it is running, since, as I say in my original post, ntpd_enable="YES" is enabled in /etc/rc.conf. Therefore, I take it I wouldn't want to run # sysrc ntpd_enable=YES. But, since I never ran service ntpd start after installing FreeBSD, is that something I was supposed to do? If so, would just running that command (please specify whether I should be root) and rebooting the computer set the time?

Otherwise, is ntpdate 0.freebsd.pool.ntp.org something I should run as root?

eternal_noob said:
If you read his other thread, you'll get that he wants to know every little detail before doing anything.

I wouldn't say I need to know every little detail, but I do need to know things like if I should be logged in as root and every command I should run. I am new to Unix, but I am trying to learn.

eternal_noob · Nov 24, 2021

Scribner said:
I do need to know things like if I should be logged in as root

You'll soon get a feeling for this. As a rule of thumb: All commands which alter the state of the whole system need root privileges.

Scribner said:
I am new to Unix, but I am trying to learn.

Good! ?

VladiBG · Nov 24, 2021

Yes you need to run ntpdateas root.

SirDice · Nov 24, 2021

Scribner said:
Therefore, I take it I wouldn't want to run # sysrc ntpd_enable=YES.

The cool thing about sysrc(8) is that you can run it as many times as you want. All this does it making sure ntpd_enable="YES" is set in rc.conf, if it's already there it won't change anything. If it's not, it will get added.

Scribner said:
But, since I never ran service ntpd start after installing FreeBSD, is that something I was supposed to do?

The ntpd_enable="YES" will make sure the service is started at boot. By running service ntpd start you're starting it yourself, which is useful if you enabled the service (added it to rc.conf) but don't want to reboot to start the service. service ntpd stop will stop it, and service ntpd restart will restart it. You need to restart the service if you have made changes to /etc/ntp.conf for example.

Scribner said:
Otherwise, is ntpdate 0.freebsd.pool.ntp.org something I should run as root?

Yes. Pretty much every command that changes anything on the system itself needs to be started or run as root. Because only root is allowed to make those changes.

Time Is UTC, but Time Zone Is Local

Scribner

VladiBG

Alain De Vos

SirDice

Administrator

covacat

SirDice

Administrator

covacat

SirDice

Administrator

VladiBG

freebsd-src/usr.sbin/bsdconfig/timezone/share/zones.subr at main · freebsd/freebsd-src

Scribner

SirDice

Administrator

VladiBG

Scribner

SirDice

Administrator

eternal_noob

Scribner

SirDice

Administrator

Scribner

VladiBG

Scribner

VladiBG

Scribner

eternal_noob

VladiBG

SirDice

Administrator