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.
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 /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.
Can everybody post the contents of /etc/sysconfig/clock?
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.
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: 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.
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?