FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 09-11-2012, 06:15 PM
Thomas Bächler
 
Default Systemd and time synchronisation problems

Am 11.09.2012 19:03, schrieb mike cloaked:
> On Tue, Sep 11, 2012 at 5:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Am 11.09.2012 18:17, schrieb mike cloaked:
>
>> I guess you need to stop chrony when playing with hwclock. Maybe it is
>> enough to just delete adjtime without that command.
>>
>> Forgot to tell you (but it's probably too late now) to post the first
>> line of your /etc/adjtime, this would have told us if we are on the
>> right track.
>>
>
> OK I will try with chrony stopped - the first line of adjtime is:
>
> 0.000000 0 0.000000
>
> I saved the file as .bak before fiddling!

Okay, that means your problem is NOT a broken adjtime. This basically
says that your hardware clock does not drift.
 
Old 09-11-2012, 06:16 PM
mike cloaked
 
Default Systemd and time synchronisation problems

On Tue, Sep 11, 2012 at 5:52 PM, Thomas Bächler <thomas@archlinux.org> wrote:

> I guess you need to stop chrony when playing with hwclock. Maybe it is
> enough to just delete adjtime without that command.
>
> Forgot to tell you (but it's probably too late now) to post the first
> line of your /etc/adjtime, this would have told us if we are on the
> right track.
>

You were right - once I had stopped chrony with systemctl stop chrony
then the hwclock command works.

So I first set the system clock using date +%T -s "18:55:00"

Then hwclock --systohc

Then checked that both the system clock and hardware clock are saying
about the same and then rebooted but left /etc/adjtime in place since
rebooting seemed not to recreate this file!

Now I will wait and see if "chronyc tracking" shows it has resynced in a while.

However a question is where does the hardware clock get
re-synchronised if it drifts out of time over a period unless it is
occasionally resynchronised?

--
mike c
 
Old 09-11-2012, 06:18 PM
mike cloaked
 
Default Systemd and time synchronisation problems

On Tue, Sep 11, 2012 at 7:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:

>> OK I will try with chrony stopped - the first line of adjtime is:
>>
>> 0.000000 0 0.000000
>>
>> I saved the file as .bak before fiddling!
>
> Okay, that means your problem is NOT a broken adjtime. This basically
> says that your hardware clock does not drift.
>

The adjtime file has now changed:

0.000000 1347386033 0.000000
1347386033
UTC



--
mike c
 
Old 09-11-2012, 06:27 PM
Thomas Bächler
 
Default Systemd and time synchronisation problems

Am 11.09.2012 20:16, schrieb mike cloaked:
> However a question is where does the hardware clock get
> re-synchronised if it drifts out of time over a period unless it is
> occasionally resynchronised?

Three things:

1) On boot, the hardware clock is copied to the system clock. The
adjtime file says how much time has to be added/removed to compensate
for drift.
2) When chrony is not running, systemd-timedated runs periodically to
adjust the hardware clock for drift (AFAIK, not sure that is the job
that timedated does).
3) When chrony is running, chrony adjusts the hardware clock for drift.
 
Old 09-11-2012, 06:51 PM
Jan Steffens
 
Default Systemd and time synchronisation problems

On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> 2) When chrony is not running, systemd-timedated runs periodically to
> adjust the hardware clock for drift (AFAIK, not sure that is the job
> that timedated does).

No. When chrony isn't running, the hwclock isn't getting adjusted at
all. The only thing systemd does on startup is warp the system clock
if and only if the RTC is running in localtime.

systemd-timedated's job is to provide a DBus interface to change
system time and date settings:
SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime),
SetNTP (whether NTP is enabled)
It's used by gnome-control-center, at least. The SetNTP call uses the
ntp-units.d directory to select an implementation.
 
Old 09-11-2012, 07:03 PM
Thomas Bächler
 
Default Systemd and time synchronisation problems

Am 11.09.2012 20:51, schrieb Jan Steffens:
> On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> 2) When chrony is not running, systemd-timedated runs periodically to
>> adjust the hardware clock for drift (AFAIK, not sure that is the job
>> that timedated does).
>
> No. When chrony isn't running, the hwclock isn't getting adjusted at
> all. The only thing systemd does on startup is warp the system clock
> if and only if the RTC is running in localtime.

Hm, sad, I had hoped it would take care of this. Seems I misunderstood
the purpose of timedated.
 
Old 09-11-2012, 07:06 PM
mike cloaked
 
Default Systemd and time synchronisation problems

On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
> On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> 2) When chrony is not running, systemd-timedated runs periodically to
>> adjust the hardware clock for drift (AFAIK, not sure that is the job
>> that timedated does).
>
> No. When chrony isn't running, the hwclock isn't getting adjusted at
> all. The only thing systemd does on startup is warp the system clock
> if and only if the RTC is running in localtime.
>
> systemd-timedated's job is to provide a DBus interface to change
> system time and date settings:
> SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime),
> SetNTP (whether NTP is enabled)
> It's used by gnome-control-center, at least. The SetNTP call uses the
> ntp-units.d directory to select an implementation.

Thank you for all the information - it seems that the key to this was
that the RTC was too far out from correct time at boot - now that I
manually set the RTC to correct time it comes up close to correct -
and then chrony synchronises a few minutes after startup. At present
tracking shows it is about 0.1 microsecs from NTP time:
System time : 0.000000106 seconds fast of NTP time

What I don't understand is why the hardware clock was not re-written
with the correctly synchronised time previously, since chrony has been
running every time I booted the system for ages?
--
mike c
 
Old 09-11-2012, 09:22 PM
mike cloaked
 
Default Systemd and time synchronisation problems

On Tue, Sep 11, 2012 at 8:06 PM, mike cloaked <mike.cloaked@gmail.com> wrote:
> On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
>> On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>>> 2) When chrony is not running, systemd-timedated runs periodically to
>>> adjust the hardware clock for drift (AFAIK, not sure that is the job
>>> that timedated does).
>>
>> No. When chrony isn't running, the hwclock isn't getting adjusted at
>> all. The only thing systemd does on startup is warp the system clock
>> if and only if the RTC is running in localtime.
>>
>> systemd-timedated's job is to provide a DBus interface to change
>> system time and date settings:
>> SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime),
>> SetNTP (whether NTP is enabled)
>> It's used by gnome-control-center, at least. The SetNTP call uses the
>> ntp-units.d directory to select an implementation.
>
> Thank you for all the information - it seems that the key to this was
> that the RTC was too far out from correct time at boot - now that I
> manually set the RTC to correct time it comes up close to correct -
> and then chrony synchronises a few minutes after startup. At present
> tracking shows it is about 0.1 microsecs from NTP time:
> System time : 0.000000106 seconds fast of NTP time
>
> What I don't understand is why the hardware clock was not re-written
> with the correctly synchronised time previously, since chrony has been
> running every time I booted the system for ages?


By the way I also found another way to write the hardware clock from
within chrony which does not need the chronyd daemon to be stopped
(after spending this evening reading the detailed chrony docs!) that
you can run chronyc in a terminal, and then enter "password
mypasswordforchrony" (where the argument is the password from the
chrony keys file) and then issue the "trimrtc" command once the chrony
password has been accepted - this will then write the current system
time to the RTC, only sensible if time has been synchronised - though
the RTC is only accurate to within a second or so I believe.

I guess it would be nice to have more complete information on the
archwiki though there is full documentation on the chrony main web
page.

--
mike c
 
Old 09-12-2012, 12:02 PM
"Stephen E. Baker"
 
Default Systemd and time synchronisation problems

On 11/09/2012 5:22 PM, mike cloaked wrote:

On Tue, Sep 11, 2012 at 8:06 PM, mike cloaked <mike.cloaked@gmail.com> wrote:

On Tue, Sep 11, 2012 at 7:51 PM, Jan Steffens <jan.steffens@gmail.com> wrote:

On Tue, Sep 11, 2012 at 8:27 PM, Thomas Bächler <thomas@archlinux.org> wrote:

2) When chrony is not running, systemd-timedated runs periodically to
adjust the hardware clock for drift (AFAIK, not sure that is the job
that timedated does).

No. When chrony isn't running, the hwclock isn't getting adjusted at
all. The only thing systemd does on startup is warp the system clock
if and only if the RTC is running in localtime.

systemd-timedated's job is to provide a DBus interface to change
system time and date settings:
SetTime, SetTimezone, SetLocalRTC (whether RTC is in localtime),
SetNTP (whether NTP is enabled)
It's used by gnome-control-center, at least. The SetNTP call uses the
ntp-units.d directory to select an implementation.

Thank you for all the information - it seems that the key to this was
that the RTC was too far out from correct time at boot - now that I
manually set the RTC to correct time it comes up close to correct -
and then chrony synchronises a few minutes after startup. At present
tracking shows it is about 0.1 microsecs from NTP time:
System time : 0.000000106 seconds fast of NTP time

What I don't understand is why the hardware clock was not re-written
with the correctly synchronised time previously, since chrony has been
running every time I booted the system for ages?


By the way I also found another way to write the hardware clock from
within chrony which does not need the chronyd daemon to be stopped
(after spending this evening reading the detailed chrony docs!) that
you can run chronyc in a terminal, and then enter "password
mypasswordforchrony" (where the argument is the password from the
chrony keys file) and then issue the "trimrtc" command once the chrony
password has been accepted - this will then write the current system
time to the RTC, only sensible if time has been synchronised - though
the RTC is only accurate to within a second or so I believe.

I guess it would be nice to have more complete information on the
archwiki though there is full documentation on the chrony main web
page.

I think the usual response is, anyone can edit the wiki - please add
what you

think is needed.
 
Old 09-12-2012, 01:59 PM
mike cloaked
 
Default Systemd and time synchronisation problems

On Wed, Sep 12, 2012 at 1:02 PM, Stephen E. Baker
<baker.stephen.e@gmail.com> wrote:

> I think the usual response is, anyone can edit the wiki - please add what
> you
> think is needed.

Point taken - I will try find some time to do that!

--
mike c
 

Thread Tools




All times are GMT. The time now is 08:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org