Time Is UTC, but Time Zone Is Local

OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

I'll run # ntpdate 0.freebsd.pool.ntp.org as a last resort because that seems like manually setting the clock. I would prefer to get my clock fixed so the system automatically sets the time.

I take it because service ntpd status doesn't alter the state of the whole system (see below), you wanted me to run it as a regular user, not root. But, still, shouldn't that command have returned that ntpd is running?

Also, you can ignore the part in my last reply where I ask if I should run service ntpd start and if I should run the command as root. It is my understanding, based on my other thread, that that command would want to be run as root, but also that ntpd should have automatically started after the first reboot, anyway.

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.
Thanks!

From my vantage point, at this point the issue seems like it's with ntpd. I did run # service ntpd status as root (I take it this was safe, but it's probably better to run that command as a regular user), and it still says it's not running.

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.
I will try running that command then. But would a better way for writing the command/syntax be # sysrc ntpd_enable="YES" (note the quotation marks)? I just see that's how the other lines are written in /etc/rc.conf. Thanks for the rest of your post; I read it after I had already begun writing my reply.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

I'll run # ntpdate 0.freebsd.pool.ntp.org as a last resort because that seems like manually setting the clock. I would prefer to get my clock fixed so the system automatically sets the time.
Yes, and the best approach to get your clock fixed is to run that ntpdate(8) command manually once, just to get the clock in sync now. Then let ntpd(8) do it's magic by keeping it synced in the background.
But would a better way for writing the command/syntax be # sysrc ntpd_enable="YES" (note the quotation marks)?
In this case it actually doesn't matter if there are quotation marks around it. But for the sake of consistency, yeah, sure.

From my vantage point, at this point the issue seems like it's with ntpd. I did run # service ntpd status as root (I take it this was safe, but it's probably better to run that command as a regular user), and it still says it's not running.
If you try to start it and it's already running it will tell you it's already running, yes, it's safe to do. If it starts, or at least says it has started the service, and you do a service ntpd status it should tell you it was started and is running. If it's not running, it failed to start for some reason. Most likely cause of that is a typo or error in /etc/ntp.conf. The default config should be fine, it's not perfect but it shouldn't cause errors.

To get the best results from NTP you need to look up a more 'local' NTP service. You can find them here: https://www.pool.ntp.org/zone/
 
OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

I just ran # sysrc ntpd_enable="YES". It returned ntpd_enable: YES -> YES. After rebooting, the clock is still set to UTC. % service ntpd status still returns ntpd is not running..
 
OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

Yes, and the best approach to get your clock fixed is to run that ntpdate(8) command manually once, just to get the clock in sync now. Then let ntpd(8) do it's magic by keeping it synced in the background.
I thought it would just be easier to tell if ntpd is fixed by seeing if my computer displays an accurate time. Shouldn't ntpd run each time at boot (re: "in the background")?

If you try to start it and it's already running it will tell you it's already running, yes, it's safe to do. If it starts, or at least says it has started the service, and you do a service ntpd status it should tell you it was started and is running. If it's not running, it failed to start for some reason. Most likely cause of that is a typo or error in /etc/ntp.conf. The default config should be fine, it's not perfect but it shouldn't cause errors.
Note that I haven't tried manually starting the service. Should I try running # service ntpd start (probably unneccessary because it should automatically start at boot)?

So do you think the problem lies with the file /etc/ntp.conf? I don't believe I made any edits to that file. How would I go about investigating and fixing this issue.

To get the best results from NTP you need to look up a more 'local' NTP service. You can find them here: https://www.pool.ntp.org/zone/
So are you saying it would be better to run # ntpdate 0.us.pool.ntp.org than # ntpdate 0.freebsd.pool.ntp.org?

I should say at this point that I did not enable the ntpdate service in the system configuration when I installed FreeBSD. I chose not to enable this service because the Handbook says:
ntpdate - Enable the automatic clock synchronization at boot time. The functionality of this program is now available in the ntpd(8) daemon. After a suitable period of mourning, the ntpdate(8) utility will be retired.

To me, that sounded like it was an old service and I should just use ntpd instead. Do you think this could be the problem? If so, is there any way to enable the ntpdate service now, or should I reinstall FreeBSD?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

I thought it would just be easier to tell if ntpd is fixed by seeing if my computer displays an accurate time.
Yes, but the problem is that ntpd(8) won't make that change if the 'jump' in time is too big.
Should I try running # service ntpd start (probably unneccessary because it should automatically start at boot)?
If you have ntpd_enable="YES" in rc.conf, then yes, it should have started at boot. Check if it's running with service ntpd status. Or ps -aux | grep ntp

To me, that sounded like it was an old service and I should just use ntpd instead.
Yes, using ntpdate(8) as a service (in other words *_enable it in rc.conf), but it's still useful as a quick command to run.

If so, is there any way to enable the ntpdate service now, or should I reinstall FreeBSD?
No need to reinstall. Just run, in order, tzsetup (set your timezone correctly). ntpdate 0.us.pool.ntp.org (this might give a big jump forwards or backwards in time). Then check if ntpd(8) is running and enabled in rc.conf, restart it just to be sure service ntpd restart.

Now, the date(1) command should give you a proper time and date. You don't need to do anything else. It takes a bit of time for ntpd(8) to 'settle' down. Time keeping is serious business. Just keep an eye on date(1) (or some other application that shows the time).

You can periodically do ntpdate -q 0.us.pool.ntp.org to see how far off the mark your local clock is compared to the internet time source.
 

Jose

Daemon

Reaction score: 1,081
Messages: 1,303

I thought it would just be easier to tell if ntpd is fixed by seeing if my computer displays an accurate time.
I like to use the ntpq(8) command to see the details of how my NTP daemon is working. Note that this command is not available for Opentpd. Here's the output of the ntpq(8) "peers" command on my server that uses the default ntp.conf(5):
Code:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.000
+69.130.244.141  64.250.105.228   3 u  484 1024  377   57.233   +1.569   2.763
-ntp3.junkemailf 216.218.254.202  2 u  395 1024  377    4.066   +3.138  30.650
+mail.eaanderson 130.207.244.240  2 u  402 1024  377   48.850   +3.867   0.945
*c-73-239-136-18 50.35.73.228     2 u   71 1024  377   40.531   -2.036   1.455
-jane.qotw.net   42.20.202.230    2 u  791 1024  377   48.876   +4.827   0.846
As you can see, my clock is offset by 2 milliseconds from its peer. The characters to the left of the servers' names are their status. The character "*" means peer, "+" means candidate, and "-" means outlier. You can see more details with the "associations" command:
Code:
ntpq> as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 34431  8811   yes  none  none    reject    mobilize  1
  2 34432  14fa    no   yes  none candidate    sys_peer 15
  3 34433  13fa    no   yes  none   outlier    sys_peer 15
  4 34434  14fa    no   yes  none candidate    sys_peer 15
  5 34435  16fa    no   yes  none  sys.peer    sys_peer 15
  6 34436  13fa    no   yes  none   outlier    sys_peer 15
Exit ntpq(8) with "quit" or just "q".
To me, that sounded like it was an old service and I should just use ntpd instead. Do you think this could be the problem? If so, is there any way to enable the ntpdate service now, or should I reinstall FreeBSD?
They do different things. The ntpdate(8) command sets the date and time abruptly all at once. Time may actually appear to go backwards by a non-trivial amount. Many daemons cannot cope with this relativistic impossibility and crash. This is why it should only be run at boot. The ntpd(8) daemon will gradually slew the time to get it closer to the reference clock's time. How this is done varies by operating system, but basically the system clock will be very gradually slowed down or sped up to adjust the time.

The ntpdate(8) utility is based on a very old version of Ntpd, and can be replaced with ntpd -q -g. That has been the plan for some time now, but hasn't happened for some reason.
 
OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

Yes, using ntpdate(8) as a service (in other words *_enable it in rc.conf), but it's still useful as a quick command to run.
It looks like you meant to agree on something about "using ntpdate(8) as a service." Did you mean to say it's old or obsolete?

No need to reinstall. Just run, in order, tzsetup (set your timezone correctly). ntpdate 0.us.pool.ntp.org (this might give a big jump forwards or backwards in time). Then check if ntpd(8) is running and enabled in rc.conf, restart it just to be sure service ntpd restart.

Now, the date(1) command should give you a proper time and date. You don't need to do anything else. It takes a bit of time for ntpd(8) to 'settle' down. Time keeping is serious business. Just keep an eye on date(1) (or some other application that shows the time).

You can periodically do ntpdate -q 0.us.pool.ntp.org to see how far off the mark your local clock is compared to the internet time source.
I didn't think there was any need to reinstall, but it's frustrating that there hasn't been an easy fix.

I didn't run # tzsetup because I already ran it earlier today. I did run # ntpdate 0.us.pool.ntp.org (as root), and that set the clock to the correct date and time. I then ran % service ntpd status (as a regular user), and it still returned ntpd is not running.. So I did as you said and ran # service ntpd restart (I take it I was supposed to run this command as root because it does something that affects the entire system), and it returned:
ntpd not running? (check /var/db/ntp/ntpd.pid).
Starting ntpd.

When I exited the root account and ran % service ntpd status (as a regular user), it still returns that ntpd is not running..

So the issue remains that ntpd is not running

I like to use the ntpq(8) command to see the details of how my NTP daemon is working. Note that this command is not available for Opentpd. Here's the output of the ntpq(8) "peers" command on my server that uses the default ntp.conf(5):
Code:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.000
+69.130.244.141  64.250.105.228   3 u  484 1024  377   57.233   +1.569   2.763
-ntp3.junkemailf 216.218.254.202  2 u  395 1024  377    4.066   +3.138  30.650
+mail.eaanderson 130.207.244.240  2 u  402 1024  377   48.850   +3.867   0.945
*c-73-239-136-18 50.35.73.228     2 u   71 1024  377   40.531   -2.036   1.455
-jane.qotw.net   42.20.202.230    2 u  791 1024  377   48.876   +4.827   0.846
As you can see, my clock is offset by 2 milliseconds from its peer. The characters to the left of the servers' names are their status. The character "*" means peer, "+" means candidate, and "-" means outlier. You can see more details with the "associations" command:
Code:
ntpq> as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 34431  8811   yes  none  none    reject    mobilize  1
  2 34432  14fa    no   yes  none candidate    sys_peer 15
  3 34433  13fa    no   yes  none   outlier    sys_peer 15
  4 34434  14fa    no   yes  none candidate    sys_peer 15
  5 34435  16fa    no   yes  none  sys.peer    sys_peer 15
  6 34436  13fa    no   yes  none   outlier    sys_peer 15
Exit ntpq(8) with "quit" or just "q".

They do different things. The ntpdate(8) command sets the date and time abruptly all at once. Time may actually appear to go backwards by a non-trivial amount. Many daemons cannot cope with this relativistic impossibility and crash. This is why it should only be run at boot. The ntpd(8) daemon will gradually slew the time to get it closer to the reference clock's time. How this is done varies by operating system, but basically the system clock will be very gradually slowed down or sped up to adjust the time.

The ntpdate(8) utility is based on a very old version of Ntpd, and can be replaced with ntpd -q -g. That has been the plan for some time now, but hasn't happened for some reason.
Thanks. This was all useful information that I, as a newbie, appreciate.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

When I exited the root account and ran % service ntpd status (as a regular user), it still returns that ntpd is not running..
That should work though:
Code:
> service ntpd status
ntpd is running as pid 91687.

Check if it's running with ps -aux | grep ntp, you should see something like this:
Code:
> ps -aux | grep ntp
ntpd   91687    0.0  0.0    18908    5820  -  Ss   10:37         0:03.97 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f
dice  41645    0.0  0.0    11360    2428  0  R+   10:20         0:00.00 grep ntp

If none of these show ntpd(8) is running something is causing it to fail to start.
 
OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

Check if it's running with ps -aux | grep ntp, you should see something like this:
Code:
> ps -aux | grep ntp
ntpd   91687    0.0  0.0    18908    5820  -  Ss   10:37         0:03.97 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f
dice  41645    0.0  0.0    11360    2428  0  R+   10:20         0:00.00 grep ntp

If none of these show ntpd(8) is running something is causing it to fail to start.
The first time I ran that command I got a bunch of stuff relating to Firefox, so I closed Firefox with nothing else open and ran it again. This time, it returned:
Code:
% ps -aux | grep ntp
<myusername> 46347  0.0  0.0     12868   2428  1  S+   08:23   0:00.00 grep ntp
Where <myusername> is my username.

I take it this means something is causing ntpd to fail to start. Do you have any ideas why, or is this subject for another thread?
 
OP
Scribner

Scribner

Active Member

Reaction score: 7
Messages: 128

Most likely cause is an error in /etc/ntp.conf. Can you post yours?
I ran # ee /etc/ntp.conf as root. Could I also have run % ee /etc/ntp.conf as a regular user, since I am only viewing--not editing--a file? I still make the mistake of doing Ctrl-C to copy when I am in a terminal, and I don't want to mess up stuff. Anyway, here's my /etc/ntp.conf file:

Code:
#
# $FreeBSD$
#
# Default NTP servers for the FreeBSD operating system.
#
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
#
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
#

#
# Set the target and limit for adding servers configured via pool statements
# or discovered dynamically via mechanisms such as broadcast and manycast.
# Ntpd automatically adds maxclock-1 servers from configured pools, and may
# add as many as maxclock*2 if necessary to ensure that at least minclock
# servers are providing good consistent time.
#
tos minclock 3 maxclock 6

#
# The following pool statement will give you a random set of NTP servers
# geographically close to you.  A single pool statement adds multiple
# servers from the pool, according to the tos minclock/maxclock targets.
# See http://www.pool.ntp.org/ for details.  Note, pool.ntp.org encourages
# users with a static IP and good upstream NTP servers to add a server
# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
#
# The option `iburst' is used for faster initial synchronization.
#
pool 0.freebsd.pool.ntp.org iburst

#
# If you want to pick yourself which country's public NTP server
# you want to sync against, comment out the above pool, uncomment
# the next one, and replace CC with the country's abbreviation.
# Make sure that the hostname resolves to a proper IP address!
#
# pool 0.CC.pool.ntp.org iburst

#
# To configure a specific server, such as an organization-wide local
# server, add lines similar to the following.  One or more specific
# servers can be configured in addition to, or instead of, any server
# pools specified above.  When both are configured, ntpd first adds all
# the specific servers, then adds servers from the pool until the tos
# minclock/maxclock targets are met.
#
#server time.my-internal.org iburst

#
# Security:
#
# By default, only allow time queries and block all other requests
# from unauthenticated clients.
#
# The "restrict source" line allows peers to be mobilized when added by
# ntpd from a pool, but does not enable mobilizing a new peer association
# by other dynamic means (broadcast, manycast, ntpq commands, etc).
#
# See http://support.ntp.org/bin/view/Support/AccessRestrictions
# for more information.
#
restrict default limited kod nomodify notrap noquery nopeer
restrict source  limited kod nomodify notrap noquery

#
# Alternatively, the following rules would block all unauthorized access.
#
#restrict default ignore
#
# In this case, all remote NTP time servers also need to be explicitly
# allowed or they would not be able to exchange time information with
# this server.
#
# Please note that this example doesn't work for the servers in
# the pool.ntp.org domain since they return multiple A records.
#
#restrict 0.pool.ntp.org nomodify nopeer noquery notrap
#restrict 1.pool.ntp.org nomodify nopeer noquery notrap
#restrict 2.pool.ntp.org nomodify nopeer noquery notrap
#
# The following settings allow unrestricted access from the localhost
restrict 127.0.0.1
restrict ::1

#
# If a server loses sync with all upstream servers, NTP clients
# no longer follow that server. The local clock can be configured
# to provide a time source when this happens, but it should usually
# be configured on just one server on a network. For more details see
# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
# The use of Orphan Mode may be preferable.
#
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10

# See http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.
# for documentation regarding leapfile. Updates to the file can be obtained
# from ftp://time.nist.gov/pub/ or ftp://tycho.usno.navy.mil/pub/ntp/.
# Use either leapfile in /etc/ntp or periodically updated leapfile in /var/db.
#leapfile "/etc/ntp/leap-seconds"
leapfile "/var/db/ntpd.leap-seconds.list"

# Specify the number of megabytes of memory that should be allocated and
# locked. -1 (default) means "do not lock the process into memory".
# 0 means "lock whatever memory the process wants into memory". Any other
# number means to lock up to that number of megabytes into memory.
# 0 may result in a segfault when ASLR with stack gap randomization
# is enabled.
#rlimit memlock 32
 

roarde

New Member

Reaction score: 1
Messages: 2

If FreeBSD is the only presently installed OS:

Reboot. Enter BIOS setup. Set the time. Add six hours to your wall-clock, and set that time. Error of no more than two minutes (I think) is okay. Reminder: It's presently evening, so you'll probably need "tomorrow's" date. Save and exit setup.

That probably fixes you. If not, run tzsetup as root again, and reply "Yes" to the first question, about whether the CMOS clock is set to UTC. Note that tzsetup doesn't clear some terminals on exit; if you can see yourself typing clear<enter> on-screen, tzsetup fully finished. Once this is all done, ntpd will probably start and stay running after boot, as expected.

FreeBSD can easily handle a CMOS clock set to local as well, but honestly it's harder for most humans to set up that way. I do admit that forgetting to add time to the wall-clock when setting time in BIOS still catches me sometimes to this day, tho.

If Windows or DOS is installed as well:

Set BIOS time directly from wall-clock, then answer "No" to first question in tzsetup. Yes, there's a registry setting that would let you use a UTC CMOS clock with Windows, but personally I'd keep it the way most other people have it until UTC finally becomes the default there.

If you have some other, additional OS installed:

Personally, I'd change them over to starting with a UTC-CMOS-clock. Opinions vary.

Future installations not Windows or DOS should be set for UTC-CMOS-clock.
 
Top