Created attachment 524442 [details]
output for log files
Description of problem:
Using 1.5-client; I would try to register the system with spacewalk using a basic activation key (only name and monitoring entitlement selected) and I would get an internal server error on the client. The server would generate some errors in attachment. Had 10000 entitlements for each field set for second organization unit.
Was everytime on any xen vm I tried. I installed a fresh one (all vms I use are clones of each other) and the same problem happened there. Running centos 5.7 domu with xen 3.1 and a centos 5.7 vm.
Steps to Reproduce:
1. Create new org
2. attach vm to org
Internal server error on client, and numerous errors on spacewalk server.
System would register as normal
A centos 6 qemu vm would attach perfectly fine. I'm running spacewalk server with postgres. Will gladly run any tests anyone asks. Oh and also, I can register the client to the default org perfectly and then migrate the box over to second org and use box as normal. Just attaching fails. Will soon test with 3rd org just in case.
Just created a 3rd repo with entitlements and it connected fine. So something wrong with 2nd one. I named the second one tOm (were theOthermedia) so maybe it something to do with that?
There is still a bug here, but could be something strange
created a 3rd organization unit sorry
update; between creating the 3rd unit and setting it up for general use I have somehow triggered the bug again. It was working and now without touching the entitlements (everything is set to 10k) it no longer works.
Sorry for the spam, I had systems registering happily on the 2nd org before I left work last night. The only thing I was doing was migrating the systems between the 1st and 3rd org. As of this morning it's no longer working.
I would welcome some instructions to do stuff step by step to see what breaks if anyone thinks this bug is serious or not seen before. For now im going to do things very slowly and test after each time to see if I can narrow it down. It only appears to affect xen vm's and i'm convinced its something to do with virtual machine entitlements.
Final comment on this unless i figure out a work around. Basically the problem only seems to persist when the parent xen host is in the same org and has a base entitlement enabled.
I would be perfectly happy having xen image as a standalone server but am struggling to find a way without having to migrate boxes across (which obivously loses all their groups, channel info, etc)
We'd need to figure out which entitlement it's failing on.
Could you please patch your driver_postgresql.py with
--- /usr/lib/python2.4/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py.orig 2011-12-08 13:00:10.000000000 -0500
+++ /usr/lib/python2.4/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py 2011-12-09 08:27:01.000000000 -0500
@@ -82,7 +82,15 @@
query = "SELECT %s(%s)" % (self.name, positional_args)
log_debug(2, query, args)
- ret = self.cursor.execute(query, args)
+ ret = self.cursor.execute(query, args)
+ except psycopg2.Error, e:
+ error_code = 99999
+ m = re.match('ERROR: +-([0-9]+)', e.pgerror)
+ if m:
+ error_code = int(m.group(1))
+ raise sql_base.SQLError(error_code, e.pgerror, e)
if self.ret_type == None:
and reproduce the error? The log file should have slightly different traceback.
Created attachment 544555 [details]
Latest error log output
After failed attach of xen box after posted patch
Oh and cheers for looking into this :)
The rvii issue from the last traceback is fixed in Spacewalk nightly, with the change
If you apply this change, does it make things work, or do you get yet another traceback?
Just made the change, it certainly appears to work! Im having issues deleting the original system off spacewalk, but with the xen master node having entitlements, I was able to attach a xen instance on that box to spacewalk without any issues.
I'd say problem fixed! Thank you very much Jan for looking into it for me.
Spacewalk 1.6 has been released.