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--
/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--