Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 621853 - busybox hwclock have different behavior under first kernel and second kernel
busybox hwclock have different behavior under first kernel and second kernel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: busybox (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Denys Vlasenko
qe-baseos-daemons
: RHELNAK
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-06 06:00 EDT by Chao Ye
Modified: 2011-05-19 09:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:08:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0559 normal SHIPPED_LIVE busybox bug fix update 2011-05-18 13:57:17 EDT

  None (edit)
Description Chao Ye 2010-08-06 06:00:48 EDT
Description of problem:
When I trigger a crash, and drop it to shell. I noticed that the 'busybox hwclock' have different behavior under first kernel and second kernel.

In the first kernel:
[root@nec-em12 ~]# cat /etc/adjtime 
0.000000 1281064728 0.000000
1281064728
UTC
[root@nec-em12 ~]# echo $TZ

[root@nec-em12 ~]# hwclock --show
Fri 06 Aug 2010 05:30:47 PM CST  -0.516198 seconds
[root@nec-em12 ~]# hwclock --utc
Fri 06 Aug 2010 05:31:03 PM CST  -0.203373 seconds
[root@nec-em12 ~]# busybox hwclock --show
Fri Aug  6 09:31:16 2010  0.000000 seconds
[root@nec-em12 ~]# busybox hwclock --utc
Fri Aug  6 17:31:18 2010  0.000000 seconds  <===Seems neither UTC nor CST.
[root@nec-em12 ~]# export TZ=UTC
[root@nec-em12 ~]# hwclock --show
Fri 06 Aug 2010 09:32:38 AM UTC  -0.031608 seconds
[root@nec-em12 ~]# hwclock --utc
Fri 06 Aug 2010 09:32:40 AM UTC  -0.344011 seconds
[root@nec-em12 ~]# busybox hwclock --show
Fri Aug  6 09:32:41 2010  0.000000 seconds
[root@nec-em12 ~]# busybox hwclock --utc
Fri Aug  6 09:32:43 2010  0.000000 seconds

In the second kernel:
/ # echo $TZ

/ # hwclock --show
Fri Aug  6 09:33:22 2010  0.000000 seconds
/ # hwclock --utc
Fri Aug  6 05:33:24 2010  0.000000 seconds  <===I don't know why there is 05:33.
                                                If the time is right, it should
                                                be 17:33(05:33PM is also ok).
/ # export TZ=UTC
/ # hwclock --show
Fri Aug  6 09:36:51 2010  0.000000 seconds
/ # hwclock --utc
Fri Aug  6 09:36:53 2010  0.000000 seconds


Version-Release number of selected component (if applicable):
BusyBox v1.15.1
kexec-tools-133.el6

How reproducible:
100%

Steps to Reproduce:
1.Modify /etc/adjtime, change to UTC
2.Reboot(I'm not sure if it's necessary, but I did.)
3.Trigger a crash
  
Actual results:
Different behavior, maybe incorrect time

Expected results:
Same behavior and correct time, both first kernel and second kernel

Additional info:
Comment 2 RHEL Product and Program Management 2010-08-06 06:27:37 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 Denys Vlasenko 2010-08-10 06:28:21 EDT
(In reply to comment #0)
> Description of problem:
> When I trigger a crash, and drop it to shell. I noticed that the 'busybox
> hwclock' have different behavior under first kernel and second kernel.
> 
> In the first kernel:
> [root@nec-em12 ~]# cat /etc/adjtime 
> 0.000000 1281064728 0.000000
> 1281064728
> UTC
> [root@nec-em12 ~]# echo $TZ
> 
> [root@nec-em12 ~]# hwclock --show
> Fri 06 Aug 2010 05:30:47 PM CST  -0.516198 seconds
> [root@nec-em12 ~]# hwclock --utc
> Fri 06 Aug 2010 05:31:03 PM CST  -0.203373 seconds

This means that your RTC is kept in UTC. Hmm. I wonder how hwclock knows that...

> [root@nec-em12 ~]# busybox hwclock --show
> Fri Aug  6 09:31:16 2010  0.000000 seconds
> [root@nec-em12 ~]# busybox hwclock --utc
> Fri Aug  6 17:31:18 2010  0.000000 seconds  <===Seems neither UTC nor CST.

Hmm. It added +8 hours. Which means it thinks you are in timezone 8 hours to the East from England, whereas it should at worst add -6 (i.e. CST) - assuming busybox hwclock can't figure out that RTC is already in UTC and thus --utc should be a no-op...

Please run "busybox date". What timezone does it show?

The timezone may be affected by $TZ (as you show, in your case you don't have it set, so this isn't the cause), by /etc/TZ file (it acts as "default $TZ value"), and finally, by /etc/localtime. Newer tzfile format has $TZ style string at the end. Example from my machine:

# hexdump -C /etc/localtime | tail -4
000008a0  01 01 00 00 00 00 00 00  01 01 0a 43 45 54 2d 31  |...........CET-1|
000008b0  43 45 53 54 2c 4d 33 2e  35 2e 30 2c 4d 31 30 2e  |CEST,M3.5.0,M10.|
000008c0  35 2e 30 2f 33 0a                                 |5.0/3.|

(can you run the same command on the affected machine?)

So, if neither $TZ not /etc/TZ is set, then this string is used.

The slight problem here is that this string is meant to be "the timezone rule which applies when all time transitions in /etc/localtime are in the past". Which for most timezones will be a reasonable approximation (it will exactly right, or will be wrong for a few hours or days a year at worst).

But I can imagine that some timezone files may simply have this string totally wrong, and in normal tools it will only became apparent "when all time transitions in /etc/localtime are in the past", that is, something like tens of years in the future!

> [root@nec-em12 ~]# export TZ=UTC
> [root@nec-em12 ~]# hwclock --show
> Fri 06 Aug 2010 09:32:38 AM UTC  -0.031608 seconds
> [root@nec-em12 ~]# hwclock --utc
> Fri 06 Aug 2010 09:32:40 AM UTC  -0.344011 seconds

> [root@nec-em12 ~]# busybox hwclock --show
> Fri Aug  6 09:32:41 2010  0.000000 seconds
> [root@nec-em12 ~]# busybox hwclock --utc
> Fri Aug  6 09:32:43 2010  0.000000 seconds

As expected. $TZ has highest priority, thus they both do not adjust the time.


> In the second kernel:
> / # echo $TZ
> 
> / # hwclock --show
> Fri Aug  6 09:33:22 2010  0.000000 seconds
> / # hwclock --utc
> Fri Aug  6 05:33:24 2010  0.000000 seconds  <===I don't know why there is
> 05:33.
>                                                 If the time is right, it should
>                                                 be 17:33(05:33PM is also ok).

I take it this is the busybox hwclock (0.000000 is a giveaway).
What standard one shows under this kernel?

This indeed looks weird:
on 1st kernel bbox hwclock was adding 8 hours,
on second kernel it subtracts 4 hours!

> Version-Release number of selected component (if applicable):
> BusyBox v1.15.1
> kexec-tools-133.el6
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Modify /etc/adjtime, change to UTC

Why modifying /etc/adjtime is crucial? How exactly to modify it (change third line to "UTC"?)

I see two possible bugs here:

(1) bbox hwclock needs to look at third line of /etc/adjtime
(2) bbox timezone handling is broken
    (alternatives are: you have /etc/TZ file, or your /etc/localtime
    is set to a timezone which has a bug (as I explained before,
    such bug will be nearly impossible to note normally)
Comment 4 Denys Vlasenko 2010-08-10 08:36:05 EDT
(In reply to comment #3)
> > [root@nec-em12 ~]# hwclock --show
> > Fri 06 Aug 2010 05:30:47 PM CST  -0.516198 seconds
> > [root@nec-em12 ~]# hwclock --utc
> > Fri 06 Aug 2010 05:31:03 PM CST  -0.203373 seconds
> 
> This means that your RTC is kept in UTC. Hmm. I wonder how hwclock knows
> that...

Aha! By looking at /etc/adjtime's third line!

> > [root@nec-em12 ~]# busybox hwclock --show
> > Fri Aug  6 09:31:16 2010  0.000000 seconds
> > [root@nec-em12 ~]# busybox hwclock --utc
> > Fri Aug  6 17:31:18 2010  0.000000 seconds  <===Seems neither UTC nor CST.
> 
> Hmm. It added +8 hours. Which means it thinks you are in timezone 8 hours to
> the East from England

Well, apparently it does not notice your modified /etc/adjtime.
Aha. Apparently FHS wants to move that file, and bbox has a config option to select "traditional" or "new" behavior. And it is set to "new" for RHEL6.

This might be the reason. I'll cook up a test build to check this theory.
Comment 5 Denys Vlasenko 2010-08-10 09:12:59 EDT
Please try this test build:

https://brewweb.devel.redhat.com/taskinfo?taskID=2670459

The only change in it that CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS is turned off.
Comment 6 Chao Ye 2010-08-11 02:35:19 EDT
With the old version:
===============================================================================
[root@hp-ml370g4-01 ~]# cat /etc/adjtime 
0.000000 1281505259 0.000000
1281505259
UTC
[root@hp-ml370g4-01 ~]# cat /etc/sysconfig/clock 
ZONE="America/New_York"
[root@hp-ml370g4-01 ~]# hexdump -C /etc/localtime | tail -4
00000d90  00 45 53 54 00 45 57 54  00 45 50 54 00 00 00 00  |.EST.EWT.EPT....|
00000da0  00 01 00 00 00 00 01 0a  45 53 54 35 45 44 54 2c  |........EST5EDT,|
00000db0  4d 33 2e 32 2e 30 2c 4d  31 31 2e 31 2e 30 0a     |M3.2.0,M11.1.0.|
00000dbf
[root@hp-ml370g4-01 ~]# ls /etc/TZ
ls: cannot access /etc/TZ: No such file or directory
[root@hp-ml370g4-01 ~]# echo $TZ

[root@hp-ml370g4-01 ~]# hwclock --show              -----hwclock------
Wed 11 Aug 2010 01:58:15 AM EDT  -0.688077 seconds     <========EDT
[root@hp-ml370g4-01 ~]# hwclock --utc
Wed 11 Aug 2010 01:59:14 AM EDT  -0.375322 seconds     <========EDT
[root@hp-ml370g4-01 ~]# date
Wed Aug 11 01:59:16 EDT 2010                           <========EDT
[root@hp-ml370g4-01 ~]# busybox hwclock --show      -----busybox------
Wed Aug 11 06:00:36 2010  0.000000 seconds             <==Seems UTC
[root@hp-ml370g4-01 ~]# busybox hwclock --utc
Wed Aug 11 02:00:41 2010  0.000000 seconds             <==Seems EDT
[root@hp-ml370g4-01 ~]# busybox date
Wed Aug 11 02:00:45 EDT 2010                           <========EDT
[root@hp-ml370g4-01 ~]# export TZ=UTC
[root@hp-ml370g4-01 ~]# echo $TZ
UTC
[root@hp-ml370g4-01 ~]# hwclock --show
Wed 11 Aug 2010 06:01:42 AM UTC  -0.906929 seconds
[root@hp-ml370g4-01 ~]# hwclock --utc
Wed 11 Aug 2010 06:01:43 AM UTC  -0.281593 seconds
[root@hp-ml370g4-01 ~]# date
Wed Aug 11 06:01:44 UTC 2010
[root@hp-ml370g4-01 ~]# busybox hwclock --show
Wed Aug 11 06:01:46 2010  0.000000 seconds
[root@hp-ml370g4-01 ~]# busybox hwclock --utc
Wed Aug 11 06:01:48 2010  0.000000 seconds
[root@hp-ml370g4-01 ~]# busybox date
Wed Aug 11 06:01:49 UTC 2010
-----------------------------------------------------------
/ # hwclock --show
Wed Aug 11 06:02:17 2010  0.000000 seconds             <==Seems UTC
/ # hwclock --utc
Wed Aug 11 02:02:20 2010  0.000000 seconds             <==Seems EDT
/ # date
Wed Aug 11 02:02:24 EDT 2010                           <========UTC
===============================================================================
With your test build:
[root@hp-ml370g4-01 ~]# hwclock --show              -----hwclock------
Wed 11 Aug 2010 02:18:01 AM EDT  -0.454344 seconds     <========EDT
[root@hp-ml370g4-01 ~]# hwclock --utc
Wed 11 Aug 2010 02:18:03 AM EDT  -0.469080 seconds     <========EDT
[root@hp-ml370g4-01 ~]# date
Wed Aug 11 02:18:04 EDT 2010                           <========EDT
[root@hp-ml370g4-01 ~]# busybox hwclock --show      -----busybox------
Wed Aug 11 02:18:05 2010  0.000000 seconds             <==Seems EDT
[root@hp-ml370g4-01 ~]# busybox hwclock --utc
Wed Aug 11 02:18:07 2010  0.000000 seconds             <==Seems EDT
[root@hp-ml370g4-01 ~]# busybox date
Wed Aug 11 02:18:09 EDT 2010                           <========EDT
[root@hp-ml370g4-01 ~]# export TZ=UTC
[root@hp-ml370g4-01 ~]# echo $TZ
UTC
[root@hp-ml370g4-01 ~]# hwclock --show
Wed 11 Aug 2010 06:18:33 AM UTC  -0.031710 seconds
[root@hp-ml370g4-01 ~]# hwclock --utc
Wed 11 Aug 2010 06:18:37 AM UTC  -0.422209 seconds
[root@hp-ml370g4-01 ~]# date
Wed Aug 11 06:18:38 UTC 2010
[root@hp-ml370g4-01 ~]# busybox hwclock --show
Wed Aug 11 06:18:39 2010  0.000000 seconds
[root@hp-ml370g4-01 ~]# busybox hwclock --utc
Wed Aug 11 06:18:41 2010  0.000000 seconds
[root@hp-ml370g4-01 ~]# busybox date
Wed Aug 11 06:18:43 UTC 2010
-----------------------------------------------------------
/ # hwclock --show
Wed Aug 11 02:19:59 2010  0.000000 seconds             <==Seems EDT
/ # hwclock --utc
Wed Aug 11 02:20:02 2010  0.000000 seconds             <==Seems EDT
/ # date
Wed Aug 11 02:20:05 EDT 2010                           <========EDT
Comment 7 Chao Ye 2010-08-11 02:52:42 EDT
> -----------------------------------------------------------
> / # hwclock --show
> Wed Aug 11 06:02:17 2010  0.000000 seconds             <==Seems UTC
> / # hwclock --utc
> Wed Aug 11 02:02:20 2010  0.000000 seconds             <==Seems EDT
> / # date
> Wed Aug 11 02:02:24 EDT 2010                           <========UTC
> 
Make a mistake, it should be EDT. Sorry for that.
Comment 8 Denys Vlasenko 2010-08-11 06:59:17 EDT
in other words, looks like test build works just fine?
Comment 9 Chao Ye 2010-08-11 23:20:56 EDT
Yes, I guess. I rechecked your test build with 'LOCAL', and it also works fine.
================================================================================
[root@hp-xw4200-01 ~]# cat /etc/adjtime 
0.000000 1281579191 0.000000
1281579191
LOCAL
[root@hp-xw4200-01 ~]# cat /etc/sysconfig/clock 
ZONE="America/New_York"
[root@hp-xw4200-01 ~]# hexdump -C /etc/localtime | tail -4
00000d90  00 45 53 54 00 45 57 54  00 45 50 54 00 00 00 00  |.EST.EWT.EPT....|
00000da0  00 01 00 00 00 00 01 0a  45 53 54 35 45 44 54 2c  |........EST5EDT,|
00000db0  4d 33 2e 32 2e 30 2c 4d  31 31 2e 31 2e 30 0a     |M3.2.0,M11.1.0.|
00000dbf
[root@hp-xw4200-01 ~]# ls /etc/TZ
ls: cannot access /etc/TZ: No such file or directory

.......................................

[root@hp-xw4200-01 ~]# hwclock --show
Wed 11 Aug 2010 10:46:06 PM EDT  -0.880583 seconds
[root@hp-xw4200-01 ~]# hwclock --utc
Wed 11 Aug 2010 06:46:07 PM EDT  -0.109657 seconds
[root@hp-xw4200-01 ~]# date
Wed Aug 11 22:46:08 EDT 2010
[root@hp-xw4200-01 ~]# busybox hwclock --show
Wed Aug 11 22:46:10 2010  0.000000 seconds
[root@hp-xw4200-01 ~]# busybox hwclock --utc
Wed Aug 11 18:46:12 2010  0.000000 seconds
[root@hp-xw4200-01 ~]# busybox date
Wed Aug 11 22:46:14 EDT 2010
[root@hp-xw4200-01 ~]# export TZ=UTC
[root@hp-xw4200-01 ~]# echo $TZ
UTC
[root@hp-xw4200-01 ~]# hwclock --show
Wed 11 Aug 2010 10:46:21 PM UTC  -0.844079 seconds
[root@hp-xw4200-01 ~]# hwclock --utc
Wed 11 Aug 2010 10:46:22 PM UTC  -0.484631 seconds
[root@hp-xw4200-01 ~]# date
Thu Aug 12 02:46:23 UTC 2010
[root@hp-xw4200-01 ~]# busybox hwclock --show
Wed Aug 11 22:46:26 2010  0.000000 seconds
[root@hp-xw4200-01 ~]# busybox hwclock --utc
Wed Aug 11 22:46:29 2010  0.000000 seconds
[root@hp-xw4200-01 ~]# busybox date
Thu Aug 12 02:46:31 UTC 2010
[root@hp-xw4200-01 ~]# echo c > /proc/sysrq-trigger

.......................................

/ # echo $TZ

/ # hwclock --show
Wed Aug 11 22:47:02 2010  0.000000 seconds
/ # hwclock --utc
Wed Aug 11 18:47:04 2010  0.000000 seconds
/ # date
Wed Aug 11 22:47:06 EDT 2010
/ # export TZ=UTC
/ # echo $TZ
UTC
/ # hwclock --show
Wed Aug 11 22:47:14 2010  0.000000 seconds
/ # hwclock --utc
Wed Aug 11 22:47:15 2010  0.000000 seconds
/ # date
Thu Aug 12 02:47:17 UTC 2010
/ # exit
Comment 11 Denys Vlasenko 2010-11-30 08:28:08 EST
The build which incorporates the fix:

https://brewweb.devel.redhat.com/taskinfo?taskID=2922957
Comment 14 errata-xmlrpc 2011-05-19 09:08:27 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0559.html

Note You need to log in before you can comment on or make changes to this bug.