Bug 621853
| Summary: | busybox hwclock have different behavior under first kernel and second kernel | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Chao Ye <cye> |
| Component: | busybox | Assignee: | Denys Vlasenko <dvlasenk> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.1 | CC: | asersen, azelinka, ovasik, phan, rvokal |
| Target Milestone: | rc | Keywords: | RHELNAK |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-19 13:08:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. ** (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) (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. 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. 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 > -----------------------------------------------------------
> / # 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.
in other words, looks like test build works just fine? 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 The build which incorporates the fix: https://brewweb.devel.redhat.com/taskinfo?taskID=2922957 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 |
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: