Bug 523251 - satellite sync fails after upgrade to 530
Summary: satellite sync fails after upgrade to 530
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Satellite Synchronization
Version: 530
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Pradeep Kilambi
QA Contact: Brandon Perkins
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-14 15:17 UTC by Thomas Cameron
Modified: 2009-09-17 00:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-17 00:45:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
sosreport without /tftpboot (5.16 MB, application/x-bzip2)
2009-09-14 16:03 UTC, Thomas Cameron
no flags Details
satellite-sync logs (36.80 KB, text/x-log)
2009-09-14 19:43 UTC, Scott Dodson
no flags Details

Description Thomas Cameron 2009-09-14 15:17:56 UTC
Description of problem:
After upgrading to 5.3 from 5.2, satellite-sync fails with:

09:29:30 
SYNC ERROR: unhandled exception occurred:

Exception reported from satellite.tc.redhat.com
Time: Mon Sep 14 09:29:30 2009
Exception type server.rhnSQL.sql_base.SQLError

Exception Handler Information
Traceback (most recent call last):
  File "/usr/bin/satellite-sync", line 142, in main
    return satsync.Runner().main()
  File "/usr/share/rhn/satellite_tools/satsync.py", line 212, in main
    ret = method()
  File "/usr/share/rhn/satellite_tools/satsync.py", line 286, in _step_channels
    self.syncer.process_channels()
  File "/usr/share/rhn/satellite_tools/satsync.py", line 627, in process_channels
    orgid=OPTIONS.orgid or None)
  File "/usr/share/rhn/satellite_tools/sync_handlers.py", line 221, in import_channels
    importer.run()
  File "/usr/share/rhn/server/importlib/importLib.py", line 628, in run
    self.submit()
  File "/usr/share/rhn/server/importlib/channelImport.py", line 184, in submit
    self.backend.processChannelProduct(channel)
  File "/usr/share/rhn/server/importlib/backend.py", line 1135, in processChannelProduct
    channel['channel_product_id'] = self.lookupChannelProduct(channel)
  File "/usr/share/rhn/server/importlib/backend.py", line 1205, in lookupChannelProduct
    return self.createChannelProduct(channel)
  File "/usr/share/rhn/server/importlib/backend.py", line 1220, in createChannelProduct
    beta = channel['channel_product_beta'])
  File "/usr/share/rhn/server/rhnSQL/sql_base.py", line 161, in execute
    return apply(self._execute_wrapper, (self._execute, ) + p, kw)
  File "/usr/share/rhn/server/rhnSQL/driver_cx_Oracle.py", line 118, in _execute_wrapper
    raise apply(sql_base.SQLError, ret)
SQLError: (1400, 'ORA-01400: cannot insert NULL into ("RHNSAT"."RHNCHANNELPRODUCT"."VERSION")\n', 'INSERT INTO rhnChannelProduct (id, product, version, beta) VALUES (:id, :product, :version, :beta)')

Version-Release number of selected component (if applicable):
RHN Satellite 5.3 i386.


Will attach sosreport.  I had to stop the rhn-satellite service as there were oracle processes in D state and sosreport warned that it might hang.

Comment 1 Thomas Cameron 2009-09-14 15:49:21 UTC
Wow - sosreport is almost a gigabyte, don't think it makes sense to upload it.  See http://www.camerontech.com/sosreport-tcameron.523251-394871-effb1d.tar.bz2 for the sosreport if you need it.

The only step I've taken so far per Jan Pazdziora is to delete all the content under /var/cache/rhn and re-run satellite-sync.  It did not help.  I also deleted all beta channels using satrm.py since the error references "beta."  That also did not help.

Any ideas?

Comment 2 Thomas Cameron 2009-09-14 16:03:52 UTC
Created attachment 360968 [details]
sosreport without /tftpboot

Here is the sosreport without the /tftpboot directory so it's a sane size.

Comment 3 Scott Dodson 2009-09-14 19:43:20 UTC
Created attachment 360991 [details]
satellite-sync logs

I'm seeing the same problem, log attached.

Comment 5 Scott Dodson 2009-09-16 22:30:21 UTC
I'm no longer having this problem. If Thomas can confirm I suggest we close this as a temporary networking/services problem within RHN.

Comment 6 Thomas Cameron 2009-09-17 00:45:46 UTC
Ditto here - it seems to be working now.  Closing this BZ.


Note You need to log in before you can comment on or make changes to this bug.