Arch Linux

I agree that /etc/localtime in rc.sysinit is not needed in most cases, because it's set in rc.shutdown, but additional setting in rc.sysinit was made for safety (when rc.conf was changed without calling rc.multi (from boot cd etc.)) and it's also useful for users installing via FTP from 0.7.2.

That's not my understanding, Roman. Judging from this comment
# Clock is set again later to match rc.conf
setting the clock early is misunderstood as a hack. Actually this is its correct place, if anything setting the clock the second time is a workaround for the possible unavailability of /var early on. If adjtime was kept under /etc we might as well remove the second setting.

It's too late to set /etc/localtime in rc.sysinit and we can't work around it.

When does our scheme break?
-User installing via FTP from 0.7.2
Hopefully we'll have a new ISO soon.
-User changes rc.conf without going through rc.shutdown
The "added safety" feature unmasks bugs 5445/5529. Fix one thing and break another.

So, setting /etc/localtime in rc.sysinit is either done because of a misunderstanding or provides a false illusion of safety. To make the life of future developers easier, please remove it and clear up the intention of the code.

I revived rc.sysinit once again...

1) I don't see the problem for 0.7.2 users:

a) user installs from 0.7.2 via FTP,
b) on first boot there is no /etc/localtime
c) first hwclock sets time wrong, so there will be fsck message for GMT-xx users (not for GMT+xx)
d) /etc/localtime is created
e) second hwclock sets time correct
f) user have correct time after boot
g) after reboot there will be no fsck message at all.


2) same when user changes rc.conf without going through rc.shutdown:

a) on boot there is old /etc/localtime
b) thus first hwclock sets time wrong
c) and thus there will be fsck message when localtime = GMT-xx
d) /etc/localtime is updated
e) second hwclock sets time correct

But this should be solved by user manually by copying correct file to /etc/localtime.
Setting /etc/localtime in rc.sysinit helps to always get correct localtime after boot.

Your patch neither solves nor improves this.


About /etc/adjtime vs. /var/lib/hwclock/adjtime - the second is required by FHS.
And this is not related to timezone stuff AFAIK.

This patch wasn't about fixing a bug but rather cleaning the code a bit.

I have to admit that I don't agree with setting TIMEZONE in rc.conf (HARDWARECLOCK is ok). Nobody else does it. Slackware, Gentoo, Debian, FreeBSD all keep /etc/localtime as a static copy initialized at installation. FreeBSD for example, from which Arch borrowed rc.conf, keeps most configuration in rc.conf but not timezone. The case of Gentoo is also telling: during installation the user is instructed to set the equivalent of HARDWARECLOCK in a configuration file (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8#doc_chap3) but otherwize create a copy of zoneinfo by hand, once (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7#doc_chap1). They could keep it in configuration file as well, but they don't.

Nevertheless we want to keep the way things are already done in Arch if possible.

-My idea of correct code
localtime=initial() # from installer
do
hwclock(localtime, adjtime=false)
hwclock(localtime, adjtime=true)
localtime=next() # from rc.conf
loop # reboot

-Current code, installing from 0.7.2/FTP
localtime=nil
do
hwclock(localtime, adjtime=false) # Oops, uninitialized localtime
localtime=next()
hwclock(localtime, adjtime=true)
localtime=next() # from rc.conf
loop # reboot

-Current code, installing from 0.8
localtime=initial() # from installer
do
hwclock(localtime, adjtime=false)
localtime=next() # Why? We wanted the two hwclocks to only differ in adjtime
hwclock(localtime, adjtime=true)
localtime=next() # from rc.conf
loop # reboot

This isn't about being wrong vs right but rather right vs righter :-)
Note that the change in initscripts required an updated installer that initialized localtime. If you must support 0.7.2/FTP installation until 0.8 is out then you need the current code as a temporary (partial) fix, but this temporary fix will probably stay there forever :-(

Anyway I have presented my case, if you are not convinced feel free to close this report. If possible, add a comment in the first time we set hwclock that says something like: We expect /etc/localtime to already match rc.conf (if it doesn't there's no point in setting the clock early).

I don't see the point in removing TIMEZONE var from rc.conf while keeping HARDWARECLOCK there (because it can be judged simply by existense of /etc/localtime). And there's nothing wrong with current way of setting clock and timezone in Arch IMO - it's more user-friendly for newbies. I don't really care much about other distros. :p

In your example, when installing from 0.8 there's nothing wrong with setting /etc/localtime in rc.sysinit because it will be the same as set by installer anyway.

We don't _must_ to support installation from 0.7.2. Anyway if some hack should be done for supporting 0.7.2 installer - it should be done in initscripts.install file IMO.
Setting /etc/localtime in rc.sysinit is done to escape from time error when user changes rc.conf without going through rc.shutdown, but as a side effect - it also helps users installing from 0.7.2 via FTP.

AFAIK 0.8 installer is already modified to create proper /etc/localtime.

Additional comment # We expect /etc/localtime to already match rc.conf
is not needed for this, because it's clearly visible from the next line where check for /etc/localtime existence is made.

So, there won't be any changes in rc.sysinit/rc.conf.