You are not logged in.

#26 2013-07-05 01:25:32

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: NTP and UTC woes.

I read through the wiki page and I have to say that it actually sounds rather complicated. It isn't clear to me from there whether chrony can automatically adjust the hardware clock if required. Nor is it clear whether there is any way of automating it without the use of Network Manager. And I am generally somewhat dubious about storing passwords for anything in plain text files but the wiki doesn't explain why this is safe or how to secure it if it is not.

This is not to say that chrony is not an improvement over ntpd - it may well be. But it does not look like the kind of thing I could set up in a few minutes and forget about whereas my experience with ntp has generally been that I can (or could if I understood the hardware clock thing correctly which is hardly ntp's fault).


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#27 2013-07-05 01:26:09

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: NTP and UTC woes.

Uncontrolled meaning one couldn't easily predict them.  And /etc/adjtime and /var/lib/crony/chrony.drift do not influence the accuracy of the hardware clock or how sensitive programs are to changes in timing.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#28 2013-07-05 01:40:54

Tarqi
Member
From: Ixtlan
Registered: 2012-11-27
Posts: 179
Website

Re: NTP and UTC woes.

WonderWoofy wrote:

I too tend to think that running ntpd.service contstantly is a bit silly though.

If you use nfs, as example, it would be a good idea to keep the machines in (close) sync, otherwise you will notice some weird behaviour.

cfr wrote:

Well that cannot be working on my machine given that the clocks were clearly not synchronised.

Without further research, this might be the case because the drift has been to large. Once corrected manually, it should work as stated (i believe that something like this has been happend to me too).

brebs wrote:

Ntpd is old[...]

Pointless statement.


Knowing others is wisdom, knowing yourself is enlightenment. ~Lao Tse

Offline

#29 2013-07-05 02:43:08

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: NTP and UTC woes.

I just set up chrony out of pure curiosity.  The config explains everything you need to know in great detail.  Unfortnately the man pages are rather lacking and just refer you to the chrony manual on the web.  That manual is rather extensive.  But like ntpd, there is quiet a bit of functioanlity that I don't really need on this machine.  Though maybe it might be good to set up my file server as a time server as well.

cfr wrote:

It isn't clear to me from there whether chrony can automatically adjust the hardware clock if required.

This is also explained in the configuration file.  It does indeed have this ability. 

I am kind of leaning towards the idea that maybe your rtc is so off that it might not be updated because it is too far out of whack.  I think you need to do a "ntpd --panicgate --quit && hwclock --utc --systohc" and then see if things start updating again.  BTW, what does your rtc report (hwclock --show) and what does your system show (date --utc)?

Offline

#30 2013-07-05 02:52:36

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: NTP and UTC woes.

Do you mean what did it show or what does it show?

Past results are in https://bbs.archlinux.org/viewtopic.php … 3#p1296043.

Current:

hwclock

Dydd Gwener 05 mis Gorffennaf 2013 03:49:38 BST  -0.532044 seconds

timedatectl 

      Local time: Gwe 2013-07-05 03:50:04 BST
  Universal time: Gwe 2013-07-05 02:50:04 UTC
        Timezone: Europe/London (BST, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sul 2013-03-31 00:59:59 GMT
                  Sul 2013-03-31 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sul 2013-10-27 01:59:59 BST
                  Sul 2013-10-27 01:00:00 GMT

(Similarly date --utc etc.)

Even though I corrected it using hwclock -w yesterday. Actually, I guess that's right. Does hwclock usually report in local time?

Last edited by cfr (2013-07-05 02:53:41)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#31 2013-07-05 11:33:19

rebootl
Member
Registered: 2012-01-10
Posts: 431
Website

Re: NTP and UTC woes.

Does hwclock usually report in local time?

As you can see in your output of hwclock it says BST. So I would say that's what it usually does wink

Do you have /etc/adjtime now ? The wiki says it's created by issuing

timedatectl set-local-rtc 0

Mine simply contains

UTC

. Maybe creating this file could help? I think I created it by hand, never used timedatectl.

I would say this output looks right, however your past output is really strange...

Last edited by rebootl (2013-07-05 11:33:54)


Personal website: reboot.li
GitHub: github.com/rebootl

Offline

#32 2013-07-05 23:20:11

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: NTP and UTC woes.

Yes, I have /etc/adjtime now:

0.000000 1372902698 0.000000
1372902698
UTC

CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

Board footer

Powered by FluxBB