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
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.
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
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
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.
/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
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.
The -u thing in the documentation is a leftover from apmd 2.x. It's an obsolete
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
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.
*** setclock Sat Sep 25 21:36:49 1999
--- setclock-fixed Wed Feb 2 17:46:12 2000
*** 21,27 ****
! if [ $UTC = "true" ]; then
if [ $ARC = "true" ]; then
--- 21,27 ----
! if [ $UTC = "true" -o "$UTC" = "yes" ]; then
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.