Bug 74797 - redhat-config-date crashes with a python traceback
Summary: redhat-config-date crashes with a python traceback
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-date
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
: 76798 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-01 19:13 UTC by Tom Wood
Modified: 2008-08-01 16:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-10-22 16:54:15 UTC
Embargoed:


Attachments (Terms of Use)
Per your request (36 bytes, text/plain)
2002-10-16 15:16 UTC, Tom Wood
no flags Details
Contents of /etc/sysconfig/clock and the errors from redhat-config-date (841 bytes, text/plain)
2002-10-18 19:46 UTC, Tom Wood
no flags Details

Description Tom Wood 2002-10-01 19:13:26 UTC
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):


How reproducible:
Always

Steps to Reproduce:
1.Run redhat-config-date/time
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.

Additional info:

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 ?
    mainWindow.mainWindow().stand_alone()
  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__
    self.setCurrent(self.currentEntry)
  File "/usr/share/redhat-config-date/timezone_map_gui.py", line 180, in setCurrent
    self.markers[self.currentEntry.tz].hide()
AttributeError: 'NoneType' object has no attribute 'tz'

Note that this also happened in the beta.  Guess it just wasn't caught.

Comment 1 Need Real Name 2002-10-06 20:58:12 UTC
Replicated here on this RH 8.0 Workstation on Intel P4 1.7 ghz box

Comment 2 Need Real Name 2002-10-10 19:21:22 UTC
Happens here also, fresh server install with gnome but not kde

Comment 3 Thomas Smith 2002-10-11 06:48:12 UTC
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
/usr/share/redhat-config-date/timezone_map_gui:

self.markers[self.currentEntry.tz].show()
# self.currentEntry = entry
self.markers[self.currentEntry.tz].hide()

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.

Comment 4 Brent Fox 2002-10-14 19:39:13 UTC
Can everybody post the contents of /etc/sysconfig/clock?

Comment 5 Thomas Smith 2002-10-14 21:15:18 UTC
Listing:

rw-r--r--    1 root     root           36 Oct 11 02:53 clock

Contents:

ZONE="America/New_York"
UTC=0
ARC=0

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.


Comment 6 Brent Fox 2002-10-14 23:36:40 UTC
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.

Comment 7 Thomas Smith 2002-10-15 04:53:46 UTC
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:

ZONE=
UTC=0
ARC=0

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.

Comment 8 Brent Fox 2002-10-15 13:24:31 UTC
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...

Comment 9 Thomas Smith 2002-10-15 21:05:53 UTC
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.

Comment 10 Tom Wood 2002-10-16 15:16:12 UTC
Created attachment 80664 [details]
Per your request

Comment 11 Brent Fox 2002-10-16 15:45:51 UTC
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?

Comment 12 Tom Wood 2002-10-18 19:46:22 UTC
Created attachment 80964 [details]
Contents of /etc/sysconfig/clock and the errors from redhat-config-date

Comment 13 Tom Wood 2002-10-18 19:47:55 UTC
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.

Comment 14 Brent Fox 2002-10-22 16:15:46 UTC
This has been fixed with the patch from bug 76313.  I will make a new version of
redhat-config-date available soon.

Comment 15 Tom Wood 2002-10-22 16:54:09 UTC
Many thanks, bfox!

Comment 16 Brent Fox 2002-10-22 19:03:41 UTC
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.

Comment 17 Antonio 2002-10-26 22:18:53 UTC
*** Bug 76798 has been marked as a duplicate of this bug. ***

Comment 18 Ian Pilcher 2002-10-28 14:56:31 UTC
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?

Comment 19 Brent Fox 2002-10-28 17:51:56 UTC
Huh?  I built it on an 8.0 box.  What kind of build errors are you seeing?



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