Bug 7939
| Summary: | apmd (even Raw Hide) still messes up clock | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Joe Harrington <jhmail> |
| Component: | apmd | Assignee: | Bernhard Rosenkraenzer <bero> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | jhmail |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-02-07 22:24:19 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: | |||
|
Description
Joe Harrington
1999-12-21 22:28:03 UTC
/etc/localtime isn't a symlink anymore; it's a file. As to what you're running into, it's most likely because the kernel (by default) is compiled (for APM) that the hardware clock is in UTC. Hence, if you try and set it so that it isn't, bad things *will* happen. /etc/localtime: I noticed. It doesn't stay that way long when I'm travelling. Any reason why it was changed? The symlink preserves the information of what it's set to, which is harder to get from the plain file. I *want* the clock to be in UTC. The problem is that APM doesn't always believe it. In fact, I currently have UTC=yes and no -u in /etc/sysconfig/apmd, and now when I resume I gain 5 hours. I have no idea why, it just started doing that when I went on a trip and changed the time zone. The mere fact that "yes" and "true" give different behavior is a bug. The annoying thing here is that it appears there are several ways to tell different parts of the system whether the system clock is in UTC or local, and there's no exhaustive list of all the places to set it in any manual. Deprecated options are set in active files. An option that is set by a released configuration tool is ignored. The same settings give different behavior on different days. What's going on here? Why is this so hard? If someone gives me a set of settings that they think should work consistently, I'll try them out. --jh-- The -u thing in the documentation is a leftover from apmd 2.x. It's an obsolete option. I've made some changes to the apmd scripts in current rawhide (3.0beta9-8) that should fix it. If /etc/sysconfig/clock says UTC=true or UTC=yes, it's automatically treated as UTC, no need to edit the apm configs anymore. I tried apmd-3.0final-1 from Rawhide. I still have the problem. I found the
answer.
The answer is that I'm using setclock to set the hardware clock, and $UTC=yes is
not recognized, only $UTC=true is. Note that setclock is part of the timeconfig
package, not part of apmd. A patch is below.
I have had different time recovery behavior between resumes and critical
resumes, but I haven't run my battery down recently. I'll start a new bug if
that problem persists.
I appreciate the new pcmcia shutdown, by the way. I've gotten nasty linux
crashes and resume failures from my cardbus upon resuming. Hope that's fixed by
shutting it down gracefully.
--jh--
*** setclock Sat Sep 25 21:36:49 1999
--- setclock-fixed Wed Feb 2 17:46:12 2000
***************
*** 21,27 ****
CLOCK=/sbin/clock
fi
! if [ $UTC = "true" ]; then
CLOCKFLAGS="$CLOCKFLAGS -u";
fi
if [ $ARC = "true" ]; then
--- 21,27 ----
CLOCK=/sbin/clock
fi
! if [ $UTC = "true" -o "$UTC" = "yes" ]; then
CLOCKFLAGS="$CLOCKFLAGS -u";
fi
if [ $ARC = "true" ]; then
With the fixed setclock (which I see is fixed in the current timeconfig package), everything works for me, even time resets after critical resumes. --jh-- |