RHEL 4u3 and RHCS 4u3 with all updates. system-config-cluster-1.0.25-1.0 when using system-config-cluster and [Send to cluster] to distribute the file, I get the following error message: [vega:/etc/cluster]# Traceback (most recent call last): File "/usr/sbin/system-config-cluster", line 435, in propagate if self.model_builder.exportModel(CLUSTER_CONF_PATH) == True: File "/usr/share/system-config-cluster/ModelBuilder.py", line 361, in exportModel if self.perform_final_check() == False: # failed File "/usr/share/system-config-cluster/ModelBuilder.py", line 780, in perform_final_check self.check_two_node() File "/usr/share/system-config-cluster/ModelBuilder.py", line 809, in check_two_node if self.CMAN_ptr.getAttribute('expected_votes') in ('0', '1'): AttributeError: 'NoneType' object has no attribute 'getAttribute' Distributing/applying the file from the command-line works: [vega:/etc/cluster]# ccs_tool update /etc/cluster/cluster.conf Config file updated from version 66 to 67 [vega:/etc/cluster]# cman_tool version -r 67 Also, starting ccsd on a node with this configuration file works. I have noticed that ccsd does some kind of syntax check and will not start up if it finds a problem with the file.
Created attachment 134026 [details] ignore this file
I have saved off the cluster.conf file that you attached and opened it in system-config-cluster-1.0.25-1.0. When I saved the file out, all worked fine - in fact, I dropped some printf's in and around line 809 in the Modelbuilder (where you were seeing a problem) and all worked correctly. I absolutely cannot reproduce this issue with the attached conf file. Your traceback indicates that the failure is because self.CMAN_ptr is Null. The only way this could happen is if there was not a <cman> tag in the conf file. There is an empty pointer check after loading in a conf file, which is essentially checking for missing tags...and I am NOT checking for a cman tag. I could add a check here for either a cman or gulm tag...but this still does not explain why THIS conf file is failing on your application. Could you please start system-config-cluster and choose File->Open on a copy of this file...then after it is loaded, please choose File->Save As and write it to /tmp with a new name, and see if it fails? This test will not affect your running cluster.
Created attachment 134082 [details] new file which demonstrates the problem
Oops: I uploaded the wrong file by mistake. I appologize. I uploaded the problematic configuration file. PEBKAC: Your comments were spot-on despite the wrong config file "only way this could happen is if there was not a <cman> tag in the conf file" and this is exactly what was wrong with my config file. I must have hand-edited the file and wiped the </cman> line by mistake. The python traceback syntax is somewhat daunting to me (e.g. a more friendly error message would be a "nice to have", but this is the risk I run when editing the config file by hand.) I assume cman_tool does not have the same syntax checking as system-config-cluster, which is why it did not complain. I took the liberty to closing this as NOTABUG. Once again my sincerest apologies for waisting your time