Bug 7939 - apmd (even Raw Hide) still messes up clock
apmd (even Raw Hide) still messes up clock
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: apmd (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-21 17:28 EST by Joe Harrington
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-07 17:24:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 1999-12-21 17:28:03 EST
This bug has been reported fixed many times.  It still isn't.  I posted the
following comment to the thread in bug 6052 a month ago but it's been
ignored.  See also bug 7409.  There's more to it than that, even, so please
read on...

Please REOPEN this bug.  Sorry, it isn't quite fixed, even in Raw Hide's
apmd-3.0beta9-4, and there are numerous documentation issues that have
contributed to the pain of solving this problem.

I'm on a Toshiba Tecra 8000 in EST (UTC-5:00).  I set the UTC variable in
/etc/sysconfig/clock to true, false, yes, and no, and either did or didn't
include a -u in the ADDPARAMS variable of /etc/sysconfig/apmd.  I tested
all 8 permutations.  After saving the files each time, I did:

/etc/rc.d/init.d/apmd restart ; rdate -s ntp1 ; setclock ; date

Then I suspended and restarted twice, repeating the "date" command many
times in succession during the restarts and watching the syslog messages.
In each case, the time came back set to an initial value and was then
advanced 5 hours.  Sometimes this was done incorrectly, and frequently it
was done against the instructions of the files.

Here's the truth table.

/etc/sysconfig
clock   apmd    initial final
yes     -u      -5 hr   correct
true    -u      correct +5 hr
no      -u      -5 hr   correct
false   -u      -5 hr   correct
yes             -5 hr   correct
true            correct +5 hr
no              -5 hr   correct
false           -5 hr   correct

BUG 1: If the UTC variable in /etc/sysconfig/clock is set to true, the
behavior is incorrect.  Unfortunately, this is the value that timeconfig
sets it to, rather than yes.

FIX 1: timeconfig should set it to yes, not true, and everyone reading the
file should understand both true and yes.  Document the favored value to
use in the timeconfig and sysconfig man pages.  Document the format of the
/etc/sysconfig/clock file either on its own page or in timeconfig or
sysconfig's pages.  Currently its format is undocumented in the reference
pages.

BUG 2: The -u command line option to apmd, documented under comments of the
ADDPARAMS variable of /etc/sysconfig/apmd, is completely ignored.

FIX 2: The man page says the option is ignored.  However, it also says the
hardware clock is in UTC, which may be incorrect.  The man page should be
updated.  The /etc/sysconfig/apmd file should have reference to -u removed.
The lines in /etc/rc.d/init.d/apmd that ensure the -u option is set if UTC
is set in /etc/sysconfig/clock, are not effective as they set a variable
that is never referred to.

The man pages for timeconfig, settime, and apmd refer to a program
clock(8), which doesn't exist and neither does its man page.  The correct
reference and program are "hwclock".  The man page for hwclock says it is
the man page for clock(8).  The man page for apmd doesn't give a section
number after referring to hwclock.  The man page for setclock doesn't name
a program for reading the hardware clock, but should name hwclock and state
its function.

After all of this, there is still another problem.  If I suspend with apm
-s or by holding the power button in for 1 second (configured in the BIOS
to suspend), things work fine if I'm configured with one of the methods
that work above.  However, this laptop has an emergency suspend when the
battery runs out.  When there is no power in the main batteries, it
suspends and switches to a backup battery that keeps the system alive for 8
hours in suspend mode only.  Resuming from one of these suspends (critical
resume) causes the clock to lose 5 hours and not get it back.

...And after all of *that* there's still another problem.  If you change
timezones (move the /etc/localtime link), suspend, and resume, you start
losing time all over the place.  Even once you change it back, you have to
reboot (or at least restart apmd) before it will be sensible.  This is
rough for those of us who travel a lot.

--jh--
Comment 1 Bill Nottingham 1999-12-21 17:59:59 EST
/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.
Comment 2 Joe Harrington 1999-12-22 20:44:59 EST
/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--
Comment 3 Bernhard Rosenkraenzer 2000-01-17 07:06:59 EST
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.
Comment 4 Joe Harrington 2000-02-02 17:51:59 EST
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
Comment 5 Joe Harrington 2000-02-07 17:24:59 EST
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--

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