Red Hat Bugzilla – Bug 74797
redhat-config-date crashes with a python traceback
Last modified: 2008-08-01 12:22:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Description of problem:
redhat-config-date/redhat-config-time crash with a python traceback. When
running these from the gnome menu (Red Hat -> System Settings -> Date and Time),
no actions take place.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Watch for the traceback if running from a command line.
3.Watch nothing happen if running from gnome menu.
Actual Results: Traceback was generated from command line. Traceback went to
/dev/null for menu invocation.
Expected Results: redhat-config-date/time applet should have appeared.
The traceback is as follows.
[root@fluid root]# redhat-config-time
Traceback (most recent call last):
File "/usr/share/redhat-config-date/redhat-config-date.py", line 35, in ?
File "/usr/share/redhat-config-date/mainWindow.py", line 181, in __init__
self.timezonePage = timezone_gui.timezonePage()
File "/usr/share/redhat-config-date/timezone_gui.py", line 50, in __init__
self.tz = TimezoneMap(zonetab, self.default, map=path)
File "/usr/share/redhat-config-date/timezone_map_gui.py", line 139, in __init__
File "/usr/share/redhat-config-date/timezone_map_gui.py", line 180, in setCurrent
AttributeError: 'NoneType' object has no attribute 'tz'
Note that this also happened in the beta. Guess it just wasn't caught.
Replicated here on this RH 8.0 Workstation on Intel P4 1.7 ghz box
Happens here also, fresh server install with gnome but not kde
Replicated with KDE and no Gnome installed (fresh installation). Right click on
time applet in task bar and choosing Adjust Date and Time yields some processor
action, but nothing comes up. From terminal, same as stack trace as reported in
primary bug report. Was able to fix by commenting out line 179 of
# self.currentEntry = entry
Ran a couple times, GUI came up, set timezone and time from server. Then
uncommented line 179 and tried running again. Works thereafter even with this
line uncommented, probably because the timezone is now set and this code is not
entered since there is no need to set a default.
When installing RedHat, install hung on creation of boot disk. Therefore, it is
possible that a time zone was never set by Setup Agent, which would lead to the
code of line 180. It does not seem like this code would work under any
circumstances, however, because it is definitely going to call for an attribute
of NoneType if no entry is specificed and not enter this code if an entry is
specified in the call. Am not aware of any negative externalities of simply
uncommenting line 179: Time is set correctly. clock applet is working fine, and
GUI configuration panel comes up on command.
Can everybody post the contents of /etc/sysconfig/clock?
rw-r--r-- 1 root root 36 Oct 11 02:53 clock
Note that these are the contents *after* I made the temporary code modification
and thus $ZONE was probably unspecified when I was unable to launch
redhat-config-date before (or perhaps the file was non-existent). I can try
setting $ZONE to nothing or temporarily renaming the file to replicate earlier
problem if of interest.
aldheorte, the contents of /etc/sysconfig/clock should not have been empty. I'm
almost positive that anaconda should have written a valid /etc/sysconfig/clock
file. It's going to be hard for me to reproduce the problem without knowing
what the contents of the file were originally. Maybe some of the other posters
still have the original file.
bfox, understand difficulty to reproduce, but I may have a way for you to
reproduce the bug by following up on my earlier hypotheses regarding the
misssing or incomplete /etc/sysconfig/clock file:
I renamed the clock file and selected Adjust Date & Time from the clock applet.
The data and time panel came up. I canceled the panel and checked the file. The
file was a zero byte file with no contents.
I renamed the populated file back to "clock" and then edited it to the following:
This time, the control panel did *not* come up. Thus my hypothesis is that the
/etc/sysnconfig/clock existed after installation, but ZONE was not specified.
This is possibly a result of my installation hanging at the create boot disk
step. However, if so, redhat-config-date should assume reasonable defaults for
this missing information rather than failing.
Also, if you look at the area of code I cited, I think there is a programmatic
problem aside from any observed behaviour. Please orrect me if I am wrong, as I
am no Python expert, but if that piece of code is entered, it will always fail
regardless of what the method arguments are.
No, you're absolutely right. The program should never crash even if the input
is invalid. What I'm saying is that there's another bug here somewhere if
you're /etc/sysconfig/clock file got corrupted.
If the installer hung at creating a boot disk, I don't think that would affect
/etc/sysconfig/clock because I think the installer has already written out the
file to the hard drive by that point.
I'm working on a fix that will handle the case of an invalid timezone. I think
I already handle the case where /etc/syconfig/clock has been deleted for some
reason (or is empty), but not if the timezone is invalid (i.e. not in the
zone.tab file from glibc).
I guess a sensible thing to do is to default to America/New York if the timezone
is invalid? I don't know what else to do...
Good point about the possibility of a bug in the installer or some other
program responsible for writing the configuration file, which needs tracking
of its own. Unfortunately, I am not in a position to reinstall and check this
out. I did not detect any errors prior to the boot disk stage during my
install, but I was not watching the alternative consoles. There is nothing of
interest in /root/install.log*.
As for a time zone default, I recommend GMT since this is an international
distribution and some users might not take kindly to the EST assumption. Also,
if the hardware clock is usually set to GMT anyway, it makes sense for the
time zone to match and the user to move the time zone away from the default.
After all, the user is basically doing a data transformation on GMT in the
greater scheme of things.
Created attachment 80664 [details]
Per your request
woodt, your file looks valid. In fact, it is identical to the one on my system,
and the program is not crashing for me (when the file is valid). Try running
redhat-config-date again from the command line and see if it still crashes.
Maybe the contents of the file have changed since you ran it last?
Created attachment 80964 [details]
Contents of /etc/sysconfig/clock and the errors from redhat-config-date
bfox, sorry to mislead you. Please see the attachment before this post - it's
the /etc/sysconfig/clock of the problem machine along with the errors
redhat-config-date causes. The previously posted /etc/sysconfig/clock was from
another machine, one that's probably been up2dated.
This has been fixed with the patch from bug 76313. I will make a new version of
redhat-config-date available soon.
Many thanks, bfox!
redhat-config-date-1.5.3-1 should fix the problem and should appear in Rawhide
in the next day or so. In the event that this update doesn't fix the problem,
please reopen this bug report.
Thanks for your help here, everybody.
*** Bug 76798 has been marked as a duplicate of this bug. ***
redhat-config-date-1.5.3-1 has apparently been superceded by version 1.5.4-1,
which won't build on Red Hat 8.0. Is there any way to get a working SRPM?
Huh? I built it on an 8.0 box. What kind of build errors are you seeing?