Red Hat Bugzilla – Bug 438124
[live] system-config-date backtraces when run from live image
Last modified: 2008-07-08 22:42:34 EDT
Description of problem:
system-config-date gives a backtrace when run from a live image instance.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run system-config-date from gnome-terminal in a livecd desktop session
1. Get a backtrace:
[fedora@localhost ~]$ system-config-date
Text mode interface is deprecated
Traceback (most recent call last):
File "/usr/share/system-config-date/system-config-date.py", line 87, in <module>
File "/usr/share/system-config-date/system-config-date.py", line 59, in useGuiMode
File "/usr/share/system-config-date/timeconfig.py", line 103, in <module>
timezoneBackend = timezoneBackend.timezoneBackend()
File "/usr/share/system-config-date/timezoneBackend.py", line 158, in __init__
line = lines.strip()
IndexError: list index out of range
1. to run normally
It runs ok from a normal rawhide install.
This is caused by /etc/adjtime not having information about whether or not the
system clock is UTC (i.e. it's missing the third line). I guess this is due to
hwclock being run in a virtualized environment where it simply won't work.
I'm Cc'ing Bill Nottingham and Karel Zak on this because I need to know whether
s-c-date should assume UTC or local time (or something else?) in virtualized
environments before I can fix this for real -- avoiding the traceback is easy,
but the question then is what to do with that lack of information.
The standard place (for Fedora/RHEL) where is information about UTC is
(In reply to comment #2)
> The standard place (for Fedora/RHEL) where is information about UTC is
That's funny, because I had the impression that keeping info about UTC/ARC in
there is deprecated -- about six weeks ago, Bill sent around an email with
patches to s-c-date and anaconda to get rid of storing/retrieving that info from
/etc/sysconfig/clock and use /etc/adjtime instead. Bill?
Correct. anaconda writes UTC-or-not to /etc/adjtime now, as does hwclock when run.
Not sure why it's not getting set on the live CD; in any case, defaulting to UTC
if it can't be determined is sensible.
I don't think it's got to do with Live-CD or not, but rather whether it's a
virtual machine or not. How do the system time in the host and guest OS
correlate? Is there a way for me to find out if the system time actually is set
to UTC or not?
Not AFAIK; you'd be relying on anaconda to set the right value in /etc/adjtime.
Hm, I'm a bit puzzled.
Somehow the system clock (in the guest OS) would need to know whether to adjust
for DST or not. Where from does it know that?
Whatever is written by the installer (be it in /etc/adjtime, or
/etc/sysconfig/clock for older releases. I don't think there is any other
These are evaluated in rc.sysinit and translated into options for hwclock --
which fails in a virtualized guest. What's the kernel default without hwclock
I begin to think that s-c-date should check via running "hwclock" if it runs
virtualized -- and if that's the case it should just disable the UTC checkbox
and ignore the whole thing (anaconda etc. should do the same).
What do you think?
What do you mean 'fails'?
[root@rawhide ~]# hwclock
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
That's a KVM/QEMU guest BTW.
That has nothing to do with UTC settings or not, and everything to do with there
being no /dev/rtc in the guest.
FWIW I only see the backtrace from a live usb instance not under qemu afaicr.
(In reply to comment #13)
> FWIW I only see the backtrace from a live usb instance not under qemu afaicr.
II suspect that you have (by chance?) a third line in your /etc/adjtime in the
qemu instance. Was that freshly installed or did you upgrade from something older?
(In reply to comment #12)
> That has nothing to do with UTC settings or not, and everything to do with
> there being no /dev/rtc in the guest.
OK. It's embarrassing as the s-c-date maintainer but I have to admit that I
don't know exactly how applications (via gettimeofday(), ctime(), e.a.)
determine the local time. I think the system time is always in UTC and
applications use glibc functions to determine the local "wall" time to display,
which in turn evaluate /etc/localtime or (if the TZ environment variable is set)
some file in /usr/share/zoneinfo. This would mean that the UTC setting is only
ever relevant if there is a hardware clock (i.e. /dev/rtc). Does that make sense?
Well, sort of. hwclock on boot sets the system time from the hardware clock,
with an adjustment depending on the UTC-or-not value (and the timezone).
If there's no /dev/rtc, there's nothing to sync from, so you sort of assume that
the system is correct. I suppose it could do a settimeofday() in this case.
I suppose the virt case is 435312 all over again.
(In reply to comment #15)
> Well, sort of. hwclock on boot sets the system time from the hardware clock,
> with an adjustment depending on the UTC-or-not value (and the timezone).
> If there's no /dev/rtc, there's nothing to sync from, so you sort of assume
> that the system is correct. I suppose it could do a settimeofday() in this
It being s-c-date I guess. Let's see if I get this right, s-c-date should:
- honor the UTC setting of /etc/adjtime if present, default to UTC if not
- do what with settimeofday()? I've found a way to call C-Functions from python
but I'd like to be sure what I do.
> I suppose the virt case is 435312 all over again.
I'm not sure s-c-date needs to be in the business of setting the time, aside
from calling hwclock. If it doesn't work, I'm not sure it needs to have a fallback.
In that case, should s-c-date just assume no default if this information is
missing from /etc/adjtime and write the file manually if the suer sets it to
something? Or go with what I described comment #9?
Hm, I could see either way. If hwclock doesn't work, writing the value in
/etc/adjtime won't help.
Disabling the choice if hwclock doesn't work would be the way to go then. Makes
no sense to let the user think that this setting would accomplish something when
it doesn't do that.
FWIW, if I enable time display in the KDE live image, the clock claims that the
time zone is "New York" (hence why I tried to use s-c-date in the first place ...).
I've just kicked off building system-config-date-1.9.27-1.fc9 which should:
- make the "System clock uses UTC" checkbox insensitive if hwclock doesn't work
- cope with missing UTC info in /etc/adjtime
- not write /etc/adjtime at all if it doesn't have info about the system clock
being UTC or not
Please try this out once the package is available.
Looks good to me now - at least no more backtraces. :)
system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8
system-config-date-1.9.32-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.