Description of problem: system-config-date gives a backtrace when run from a live image instance. Version-Release number of selected component (if applicable): system-config-date-1.9.24-1.fc9 How reproducible: every time Steps to Reproduce: 1. run system-config-date from gnome-terminal in a livecd desktop session Actual results: 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> useGuiMode(page) File "/usr/share/system-config-date/system-config-date.py", line 59, in useGuiMode import timeconfig 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[2].strip() IndexError: list index out of range Expected results: 1. to run normally Additional information: 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 /etc/sysconfig/clock.
(In reply to comment #2) > The standard place (for Fedora/RHEL) where is information about UTC is > /etc/sysconfig/clock. 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 communication mechanism.
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 setting it? 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'?
This: [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 > case. 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. Interesting.
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.