Mailinglist Archive: opensuse (878 mails)

< Previous Next >
Re: [opensuse] Extrange change in "/etc/sysconfig/clock"
On Sun, Sep 01, 2013 at 02:00:18PM +0200, Carlos E. R. wrote:
Content-ID: <alpine.LNX.2.00.1309011359110.7832@Telcontar.valinor>

On Sunday, 2013-09-01 at 09:14 +0400, Andrey Borzenkov wrote:

В Sat, 31 Aug 2013 20:46:35 +0200 "Carlos E. R." <> пишет:

People that double boot, specially when the other system is Windows,
who insists on the CMOS clock being localtime, often trash the adjtime
file contents. As a result, the clock shifts several hours on every
boot (maybe not an integer number of hours).

I do not understand what is to trash there. The first two lines are
legacy that nobody relies upon anyway. What this thread is about is the
third line which is never changed by hwclock itself unless you
explicitly instruct it to do so.

The first two lines are used by hwclock. The exact method varies between
openSUSE releases.

Basically, cpu time is set from cmos clock on boot. On halt system time is
copied to cmos, but first it is compared to see the difference: a value
for clock shift per time unit is stored in those first lines of the
adjtime file.

On next boot, hwclock obtains the time from cmos, and shifts it with the
difference value multiplied by the time since last cmos time set.

This procedure compensates for the inacuracies (drift) in the cmos clock.

Remember that not everybody can use ntp.

Hwclock has always stored the utc/local word there.

This is documented.

Exactly ... and hwclock always uses the third line if not specified the
option --noadjfile ... and hwclock only adjusts the Hardware Clock with
the option --adjust which should be used before doing --hctosys.

As you may see from the manual page of hwclock(8) this tool is now part
of the util-linux project and it has changed. E.g. the option --systz
has become part of hwclock(8) which does the same as my old warpclock

The cure on those cases was to set the system clock manually, transfer
contents to cmos clock, and then erase the adjtime file, in the
knowledge that rebooting would set it up correctly.

I do not understand why you need to remove /etc/adjtime helps here.
Either LOCAL/UTC was set correctly or not. If it was no correctly set
then most likely because /etc/sysconfig/clock was not set correctly and
it will be recreated with wrong value again.

When the adjustment shift in /etc/adjtime is incorrect, the file has to be
deleted and recreated correctly. UTC/LOCAL is irrelevant, but the correct
word has to be written.

If you adjust manually the clock by hours up or down, when the sihift per
unit time is calculated, it is wrong by hours. When the time is set on
next boot, it is set VERY incorrectly. People start a loop of adjusting
the clock after booting, and getting it worse on next reboot. It happens
typically to people double booting.

As the shift calculation is off, the only cure is to delete te adjtime

Nevertheless ... hwclock(8) is not used by systemd as systemd does this by
its self and for this it uses /etc/adjtime to get LOCAL(time)/UTC correct:

/home/werner> grep /etc/adjtime /etc/systemd/ /usr/lib/systemd/ -rs
Binary file /usr/lib/systemd/systemd matches
Binary file /usr/lib/systemd/systemd-timedated matches

to use the adjust functionality of hwclock(8) you may create a systemd unit
file like hwclock-adjust.service which should be type oneshot and does use

ExecStart=/usr/sbin/hwclock --adjust
ExecStart=/usr/sbin/hwclock --hwclock

and at shutdown you may need a second unit hwclock-systohc.service also
of type oneshot with

ExecStart=/usr/sbin/hwclock --systohc

Now instead I'll have (often it is me who guides these people) to tell
them a procedure to recreate the file correctly, for people that do
not even know if the cmos is running local or utc time or why that is

If people do not know whether they are running local or UTC, how are
you going to trust their /etc/sysconfig/clock then? It is user decision
in the first place, whether it is stored in /etc/sysconfig/clock
or /etc/adjtime is not important.

The right procedure to fix dual boot with Windows is to go to YaST and
set local time instead of UTC. Which will store the correct value
in /etc/adjtime. Where is the problem?

People do not remember what they did at install time. If on doubt, they
hit [ENTER]. The contents of the /etc/sysconfig/clock file allowed us
helpers to know what to do, even if the user did not know.

Now it is impossible, we have to guess for them.

And no, the correct procedure for Windows, since Vista, is to use UTC and
tell Windows to also use UTC. This, again, is documented.


Hint: find out who wrote the article.



"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
< Previous Next >
Follow Ups