How to run Linux Devuan Jessie with /dev/rtc on local time

msi · 2018-03-25 19:23:16

Just reposting this Howto here from http://188.26.90.203:8888/w/devuan-jess … o-v1.1.txt.

HOW TO RUN LINUX DEVUAN JESSIE WITH /dev/rtc ON LOCALTIME

by: Peter P. / _abc_ / ccbbaa @ irc.freenode.net
version: 1.1 - tested on one system, works fine, small fixes, terser

In this document tz is an abbreviation for timezone, and TZ is a variable set
to the local timezone.

1. The problem:

  Using RTC in local time is discouraged by manual pages and howtos, yet, people
need it, for dual boot and other reasons. It is not at all clear how to do this
even for experienced users. "Don't do it" is not the correct answer.

1.1 Initial Outcome (broken):

- RTC set to local time displays correct time in the linux system only when TZ
  is set to UTC. Otherwise, the time offset of the TZ is added even if 
  /etc/adjtimex is set to LOCAL and /etc/timezone is ln -s to the proper tz 
  file.
- This leads to insanity soon enough, especially when working remotely and or
  comparing remote log dates. Both for humans and for software. Note that all 
  date etc commands show the correct time, but the wrong tz. tz based 
  arithmetic will always be broken, like "how long ago was that server event on
  a different tz" when analyzing logs and or determining whether a host is up
  or down. Also lots of fun when working remotely with ssh on a different tz 
  machine etc.
- In addition to the above, using a set TZ causes the hw clock to be set wrong
  upon rebooting, i.e. the system hw clock will be changed in unwanted ways.

2. The solution (for the impatient):

  As root edit /etc/default/hwclock and add the line:

    export TZ="Europe/Bucharest"

  (run tzselect to find the proper tz name)

    sudo rm -f /etc/timzone
    sudo ln -s /usr/share/zoneinfo/Europe/Bucharest /etc/timzone

  (edit location exactly as above, at TZ=...)

  edit /etc/adjtimex and change the 3rd line from UTC to LOCAL

  edit /etc/profile /etc/skel/.profile and all user /home/$user/.profile
  files and add at the end:

    if [ -z "$TZ" ] && [ -r /etc/default/hwclock ]; then
      . /etc/default/hwclock
    fi

  -- done -- a reboot is required (see below why at [**]). You MUST set the
  rtc properly to local time while rebooting. Stop in BIOS setup and set it.
  Note that DST can cause problems with this system if you skip any steps.

2.8 There seems to be a bug in hwclock with at least kernel 3.16.0-4-686-pae
  (current devuan jessie):

  hwclock --show --utc run under the conditions above, shows the WRONG time,
  specifically, it applies the tz related offset positively. Example: Europe/
  Bucharest is 2 hours ahead (+120mins) of UTC. When running in localtime RTC
  as set up above, the command:

  hwclock --show --utc

  displays a time 2 hours ahead (+120mins) of LOCAL time! This is clearly a
  sign error somewhere in hwclock(8) or in the kernel.
 
3. Explanation

  The kernel and hwclock and hwclock.sh scripts changed several times, at least
once or twice due to systemd's appearance. This broke several things and was
sort of fixed several times along the times since ~2011 until today. And it
continues to be a moving target.

  The following things happen during boot time script execution:
- the kernel copies the rtc time to the kernel time some time during boot [*]
- later /etc/init.d/hwclock.sh start is executed. This will source
  /etc/default/hwclock for settings, and then run hwclock --hctosys, BUT this
  does not happen if udevd is running. If udevd is detected as running, then
  /etc/init.d/hwclock.sh start does nothing! Instead, udevd triggers 
  /lib/udev/hwclock-set at some time it likes (!) based on other rules too.
- /lib/udev/hwclock-set reads /etc/default/hwclock and then runs the following
  key commands, importantly, the 1st 1-2 times after boot [**]
  
  /sbin/hwclock --rtc=$dev --systz
  /sbin/hwclock --rtc=$dev --hctosys

- as an interesting factoid, the kernel marks the moment when it, itself, copies
  the rtc to the system clock using the sysfs. This may be important for RTC
  less systems like rpi where this is an important clue to need to copy the
  time in from some other source later, but is unrelated to the present issue:

  /sys/class/rtc/rtc0/hctosys contains 1 if rtc copied to sys

- what our humble edit above does, adding export TZ="thetimezone" in 
  /etc/default/hwclock , is: we inject an environment variable into the env
  of /sbin/hwclock when executed by /lib/udev/hwclock-set and then the hwclock
  does the right thing, setting the kernel's timezone once per boot, when it is
  FIRST executed [**]. Note /lib/udev/hwclock-set locks itself out from running
  again by writing a lock file in /var/run . Therefore, this cannot be done
  at any later time, i.e. from user mode, and it is probably not safe to change
  the kernel tz in a running system at any time, since the developers said so,
  and I am not about to prove them wrong [**]

- the remaining bug wrt hwclock --show --utc was probably introduced while other
  things were fixed. Since the source of hwclock from util-linux contains cruft
  dating back to at least 1995 (I looked), I cannot propose a quick fix, maybe
  the maintainers could take a look. Anyway, it is a minor bug.

The stars:

[*]  see the bug thread below for details
[**] the nightmare which requires this is explained briefly in the hwclock 
     manpage at or near --systz , and also in man settimeofday(2) C system
     function manual, and is also touched upon in this horrible systemd
     related thread (linked courtesy of KatolAZ on #devuan at irc.freenode.net)

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203

yeti · 2018-03-25 20:42:43

Using RTC in local time is discouraged by manual pages and howtos, yet, people
need it, for dual boot and other reasons.

Running the onboard RTC on local time and then having dual-boot with an OS that may or may not have been booted since the last switch to or from DST has taken place and will set the DST back into the RTC or the other way round is an own dimension of madness. You never can be really sure which timezone you have in the RTC.

Better let the user decide what she wants to set in her shell's rc files and run the system on UTC.

I vote for a flashing 144pt banner above this HOWTO: "Don't try this at home, kids!"
;-)

Bonus question:

What will cron do in the doubled hour when DST ends?
I never investigated this because I run my systems on UTC.
Maybe cron already has some precautions against repeating times?

golinux · 2018-03-25 21:12:55

I assumed that Linux always ran on UTC.

yeti · 2018-03-25 21:14:08

golinux wrote:

I assumed that Linux always ran on UTC.

That's the smartest way to run it.
But it allows every other madness too.

Last edited by yeti (2018-03-25 21:14:50)

pepe777 · 2018-04-10 18:44:12

@yeti strong words there. A LOT of people run the rtc in local time, with dual boot and multiple boot.
There is no question about it. The answer is wrong. Not using it is wrong. Others use it. Linux before
systemd broke things here (too). The capability was lost, as I explained, when systemd
bit into the kernel and the relevant magic setting to make hwclock work with sysvinit scripts was lost
for a while. I put it back, using the hack I described above. So @yeti you have an opinion and you
expressed it, but face reality as it is, not as we wish it to be.

Internally the kernel fakes time as-if it would be UTC else all TZ stuff will break. This is all about how the
kernel gets initialized, there is no point in discussing whether the kernel runs in UTC-like (?) mode or real
UTC. At boot time, it has to get info from a real clock and fake or set it's internals as needed to make TZ
stuff work properly. This article is exactly about that. The need for a UTC referenced TZ is cast in stone
and POSIX required too afaik. So no way that is going to change in any way.

Re: rtc: the rtc in a local system, local to some country, will probably run on local time, with DST or not,
as specified locally. It is madness to set ONE clock on UTC out of 12 or so computer RTCs because
someone said so. People keep forgetting this, it is not good. Local is local. Not server room, not pro
IT locked down, but average office or home machine.

DST works like this: the OS which is running when DST change occurs, sets the DST mode not the
RTC. There should be no misunderstanding about it. The "other" system does not spoil it. It simply
uses the same convention. In other words: the OS which is running when the DST change occurs
changes the clock. Nothing new here. When the other system boots, it is either after or before the
DST change, so ONE system changes the clock when the DST change time occurs. There are no
mysteries to it. One system is running, one system changes the clock at midnight/etc, done. The
only trick is, both systems must agree on how the clock runs during DST time. I.e. if the RTC is
advanced during DST or if DST is implemented by a flag in the OS only between certain dates,
with RTC staying unchanged. Afaik the current LOCALTIME mode in the linux kernel and hwclock
works exactly like that in Windows, assuming the DST time change is dialed into the RTC, and not
just a flag.

Conclusion: It's okay to run RTC in LOCAL time on devuan without systemd with the howto I wrote
above. - pepe777 aka user _abc_ / ccbbaa @ irc.freenode,net

The officially official Devuan Forum!

#1 2018-03-25 19:23:16

How to run Linux Devuan Jessie with /dev/rtc on local time

#2 2018-03-25 20:42:43

Re: How to run Linux Devuan Jessie with /dev/rtc on local time

#3 2018-03-25 21:12:55

Re: How to run Linux Devuan Jessie with /dev/rtc on local time

#4 2018-03-25 21:14:08

Re: How to run Linux Devuan Jessie with /dev/rtc on local time

#5 2018-04-10 18:44:12

Re: How to run Linux Devuan Jessie with /dev/rtc on local time

Board footer