This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 438124 - [live] system-config-date backtraces when run from live image
[live] system-config-date backtraces when run from live image
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-19 05:08 EDT by Jens Petersen
Modified: 2008-07-08 22:42 EDT (History)
3 users (show)

See Also:
Fixed In Version: 1.9.32-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-08 22:42:34 EDT
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 Jens Petersen 2008-03-19 05:08:05 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):
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.
Comment 1 Nils Philippsen 2008-03-19 07:46:23 EDT
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.
Comment 2 Karel Zak 2008-03-19 09:36:54 EDT
The standard place (for Fedora/RHEL) where is information about UTC is
/etc/sysconfig/clock.
Comment 3 Nils Philippsen 2008-03-19 09:46:09 EDT
(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?
Comment 4 Bill Nottingham 2008-03-19 09:51:14 EDT
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.
Comment 5 Nils Philippsen 2008-03-19 11:08:50 EDT
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?
Comment 6 Bill Nottingham 2008-03-19 11:14:00 EDT
Not AFAIK; you'd be relying on anaconda to set the right value in /etc/adjtime.
Comment 7 Nils Philippsen 2008-03-19 12:47:13 EDT
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?
Comment 8 Bill Nottingham 2008-03-19 13:02:20 EDT
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.
Comment 9 Nils Philippsen 2008-03-19 13:22:08 EDT
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?
Comment 10 Bill Nottingham 2008-03-19 13:27:33 EDT
What do you  mean 'fails'?
Comment 11 Nils Philippsen 2008-03-19 14:43:03 EDT
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.
Comment 12 Bill Nottingham 2008-03-19 14:50:15 EDT
That has nothing to do with UTC settings or not, and everything to do with there
being no /dev/rtc in the guest.
Comment 13 Jens Petersen 2008-03-19 21:18:20 EDT
FWIW I only see the backtrace from a live usb instance not under qemu afaicr.
Comment 14 Nils Philippsen 2008-03-20 06:46:27 EDT
(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?
Comment 15 Bill Nottingham 2008-03-20 10:41:59 EDT
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.
Comment 16 Nils Philippsen 2008-03-20 11:47:49 EDT
(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.

Comment 17 Bill Nottingham 2008-03-20 11:55:30 EDT
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.
Comment 18 Nils Philippsen 2008-03-20 12:41:01 EDT
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?
Comment 19 Bill Nottingham 2008-03-20 12:49:31 EDT
Hm, I could see either way. If hwclock doesn't work, writing the value in
/etc/adjtime won't help. 
Comment 20 Nils Philippsen 2008-03-20 13:25:59 EDT
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.
Comment 21 Mary Ellen Foster 2008-03-29 18:20:20 EDT
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 ...).
Comment 22 Nils Philippsen 2008-03-31 05:59:27 EDT
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.
Comment 23 Jens Petersen 2008-04-10 00:11:31 EDT
Looks good to me now - at least no more backtraces. :)
Comment 24 Fedora Update System 2008-07-01 05:53:15 EDT
system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8
Comment 25 Fedora Update System 2008-07-08 22:42:07 EDT
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.

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