Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#28458 - [initscripts] If $TIMEZONE is not set, /etc/localtime(symbol link) won't work

Attached to Project: Arch Linux
Opened by TsingYue (gfdice) - Wednesday, 15 February 2012, 16:43 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 13 March 2012, 23:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I just add a symbol link /etc/localtime to /usr/share/zoneinfo/Asia/Shanghai, and did not set $TIMEZONE in rc.conf, after the system booting process, the system's time is not right.
The time of my PC's hardware is not UTC(which is in localtime, to be compatible with the Windows system on another disk partition), so I set HARDWARECLOCK="localtime" in rc.conf, and that's all.
In /etc/rc.sysinit(2012.02.1-1) line 67:
TZ=$TIMEZONE hwclock $HWCLOCK_PARAMS && stat_done || stat_fail
In my rc.conf $TIMEZONE dose not exist, so TZ is empty(empty but exists), then `hwclock` ignored /etc/localtime with the empty TZ, and treat my timezone as "empty".
When I remove "TZ=$TIMEZONE ", everything is fine(hwclock uses /etc/localtime and HARDWARECLOCK="localtime" to set the system time). But obviously this is not compatible with those guys using $TIMEZONE in rc.conf.

Additional info:
* initscripts 2012.02.1-1

Steps to reproduce:
Set HARDWARECLOCK="localtime" in rc.conf but don't set TIMEZONE.
Link /etc/localtime to someplace like /usr/share/zoneinfo/Asia/Shanghai.
Reboot system.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 13 March 2012, 23:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  in fit (thanks dave)
Comment by Dave Reisner (falconindy) - Wednesday, 15 February 2012, 17:25 GMT
@tom: We guard set_timezone with a check for TIMEZONE, but we don't check for it before calling hwclock, so I agree with the reporter that this is inconsistent. Performing the assignment before calling hwclock fixes this.

[[ $TIMEZONE ]] && export TZ=$TIMEZONE
hwclock $HWCLOCK_PARAMS && stat_done || stat_fail
unset TZ

Loading...