|Summary:||redhat-config-date crashes with a python traceback|
|Product:||[Retired] Red Hat Linux||Reporter:||Tom Wood <woodt>|
|Component:||redhat-config-date||Assignee:||Brent Fox <bfox>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-10-22 16:54:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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 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?