Created attachment 327515 [details] trace from log after clicking "save" in system configuration After saving the configuration of a system a couple of times I get the following error: Error while saving system :maximum recursion depth exceeded in cmp After that I can no longer go to the system overview page. There I now get: Fault: <Fault 1: "<type 'exceptions.TypeError'>:object of type 'NoneType' has no len()"> The reason for that is most likely that the system configuration file "/var/lib/cobbler/config/systems.d/mymobile" has a size of 0 bytes. After deleting the file I can get back to the system overview page again. I think there are three problems here: 1) The actual recursion error 2) The fact that after such an error the configuration gets corrupted (the save handler should use a temporary file for it's work and not touch the original configuration file until the very end) 3) A corrupt system configuration file should not kill the system overview page. The page should display with an error message and the possibility to delete the offending file(s). It should still be possible to edit the other system configurations. Attached is the trace from the log for the recursion error. The cobbler version installed is: cobbler-1.4.0-2.fc10.noarch
Please supply steps to reproduce this problem.
I have been experiencing the same issue running: # rpm -qa cobbler cobbler-1.4.2-1.fc9.noarch Reproduction of the issue is not 100%, some times I can modify network settings and everything is fine while other times I get the above scenario. It has happened while adding / changing 'IP assignment', 'IP' and 'Virt Bridge' individually or any combination of them. I have also had it happen when adding a new interface (just adding and saving).
Just had it happen on this config: All I did was added a Gateway and clicked save (via the webui) and it trashed the config and left cobbler in a unstable state. cobbler system --name=test report system : test profile : f10-i386 comment : created : Mon Feb 23 14:04:16 2009 gateway : hostname : my.host.name image : kernel options : {'ksdevice': 'eth0'} kernel options post : {} kickstart : <<inherit>> ks metadata : {} mgmt classes : [] modified : Mon Feb 23 14:37:31 2009 name servers : [] netboot enabled? : True owners : ['admin'] server : <<inherit>> template files : {} virt cpus : 2 virt file size : 10 virt path : /mnt/os1 virt ram : 1024 virt type : qemu power type : apc_snmp power address : power user : power password : power id : interface : eth0 mac address : 00:16:3e:2a:ae:e7 bonding : bonding_master : bonding_opts : is static? : False ip address : subnet : static routes : [] dns name : dhcp tag : virt bridge : br9 interface : eth1 mac address : 00:16:3e:77:4a:37 bonding : bonding_master : bonding_opts : is static? : True ip address : X.X.X.X subnet : X.X.X.X static routes : [] dns name : my.host.name dhcp tag : static virt bridge : br2
I'm seeing the same issue with cobbler-1.4.1-1.el5.noarch.rpm and cobbler-1.4.2-1.el5.noarch.rpm
There was code added in 1.4.2 to eliminate this problem, though I could not repro it on my end after many tries. If you are using serializer_yaml still in /etc/cobbler/modules.conf, then that most definitely doesn't have the fix. If you are running 1.4.2 and still see a problem with serializer_catalog, then it's still present. I'm going to dig further to figure out what might be causing this. The serializer /should/ have locking code to prevent multiple writes at the same time, which was my first thought. The infinite recursion traceback I've seen in the yaml module, however, may point to that being a culprit.
Speculation about the infinite recursion problem may point to problems in the YAML library. I'm not against removing the implementation we have and replacing it with pyyaml. Anyway, that all being said, if anyone has the traceback caused by this (the infinite recursion one), please post it. I've been looking through Trac/email and can't find a copy -- still looking. If that points to yaml we'll investigate replacing our YAML library and this should be solved.
If you can provide me the steps to get the traceback, I'll gladly get it for you.
This has been talked about a lot on the list, so hopefully not closing out the BZ a while back didn't leave anyone wondering. This is fixed in 1.4.3 (swapping out the YAML parser eliminates the code that can go into an infinite recursion scenario completely), and fixed even better in 1.6 (moving to python-simplejson, where it's also nice and fast). Upgrades happen automagically. If anyone hasn't upgraded yet, they should try the latest 1.6.X and upgrade to that directly.