Description of problem:
I get an ISE when registering to webqa (18-jun-2007) if I have an installation
number on disk that indicates child channels and system entitlements to be
Version-Release number of selected component (if applicable):
rhn webqa from 18-jun-07 push
Steps to Reproduce:
1. run rhn_register to register using the GUI on a rhel 5 x86 system, with the
following installation number on disk at /etc/sysconfig/rhn/install-num:
2. register to webqa using satellite url option, https://xmlrpc.rhn.webqa.red
3. username maureenduffy
4. pops up system profile screen, click next... gives me the registering your
system... progress bar
5. then you'll get a popup error window "Problem registering system:Internal
6. i'm attaching the /var/log/up2date output.
System should be successfully registering with virt and mgmt system entitlements
and the following software channel subs: rhel5 desktop, rhn tools, desktop
multios, desktop workstation
Note that registering this system to production (rhn.redhat.com) is successful
and provides the software channels and system entitlements specified by the
Note that deleting the installation number from disk results in a successful
webqa registration. However it fails for the indicated installation number.
"<jbowes> it's blowing up at automagic child channel subscription"
Created attachment 157334 [details]
error output from /var/log/up2date
er i registered using https://xmlrpc.rhn.webqa.redhat.com/XMLRPC as the server
url, sorry about the typo
Server error log:
Exception Handler Information
Traceback (most recent call last):
File "/usr/share/rhn/server/apacheRequest.py", line 108, in call_function
response = apply(func, params)
File "/usr/share/rhn/server/handlers/xmlrpc/registration.py", line 683, in new
File "/usr/share/rhn/server/handlers/xmlrpc/registration.py", line 772, in _au
os_release_version, arch, repositories)
File "/usr/share/rhn/server/rhnChannel.py", line 1927, in subscribe_child_chan
_subscribe_sql(system_id, channel['id'], 1)
File "/usr/share/rhn/server/rhnChannel.py", line 1801, in _subscribe_sql
rhnException: (1403, 'ORA-01403: no data found', 'ORA-06512: at "RHN.RHN_CHANNEL
", line 73\nORA-06512: at "RHN.RHN_CHANNEL", line 173\nORA-06512: at line 1\n',
Making this block the -must list, since something looks like it got garbled...
John, can you check to see if this is a side-affect of your changes to then
On seconds thoughts, this probably happened because the database was updated,
but the rhnxml machine wasn't restarted. Once the restart is done, we'll have to
check again to see if it still happens
Nope, still happening
Hi, just an update, I tested this with different installation numbers and
discovered that the issue is unique to installation numbers for RHEL 5 client
that have the client-vt channel specified in them. For example:
- da3122afdb7edd23 (Red Hat Enterprise Linux Desktop + Workstation Option) works
fine, correctly subscribed to necessary child channel
- 7fcc43557e9bbc42 (Red Hat Enterprise Linux Desktop + Workstation + DualOS
Option (Virtualization)) busticated, ISE
- fed67649ff918c77 (Red Hat Enterprise Linux Desktop + DualOS Option
(Virtualization)) busticated, ISE
I noticed with my sat i've registered to webqa that I couldn't sync the
client-vt channel. So I think probably the client vt channels are missing from
So, maybe we're getting the ISE because the logic doesn't handle the case where
the IN-requested channel doesn't exist.
The registration is failing on a call from the python code to the PL/SQL stored
procedure rhn_channel.subscribe_server. In this procedure, I have added a call
to obtain_read_lock, which does a SELECT FOR UPDATE to eliminate the race
condition described in bug 239816. If for whatever reason the SELECT FOR UPDATE
returns an empty result set, oracle will raise a NO_DATA_FOUND exception, and it
is not handled; so, the exception will propagate back up to the python code. I
am going to add exception handling code so that we can throw a custom exception
that the python stack knows about.
If an exception is thrown, that would indicate that the org does not have
entitlements for the channel family. We need to verify that the org does in fact
have entitlements for the channel family.
Checked in some new exception handing code for the stored procedure
under revision 117189.
Máirín says this is cleared up now. Verified.