Bug 739009

Summary: Applying an errata on SuSe linux machines succeeds but is reported as failed to the server
Product: [Community] Spacewalk Reporter: hwinther
Component: ClientsAssignee: Duncan Mac-Vicar P. <dmacvicar>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 1.5CC: iartarisi, ma, mzazrivec, slukasik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-08 14:12:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 723481    
Attachments:
Description Flags
up2date log file
none
up2date log file of Errata Update: sledsp1-libpciaccess0-5103
none
zypper log file of Errata Update: sledsp1-libpciaccess0-5103 none

Description hwinther 2011-09-16 10:18:27 UTC
Created attachment 523535 [details]
up2date log file

Description of problem:
If you try to apply an errata for a suse linux enterprise client it is applied, but is reported as failed to the spacewalk server.


Version-Release number of selected component: 1.5.16


How reproducible:
Try to apply a software errata.

  
Actual results:
The errata is applied. Everything works as expected, but the action is reported as failed.


Expected results:
The action should be reported as success.

Comment 1 Milan Zázrivec 2011-09-16 15:09:40 UTC
Thank you for your bug report.

I'm wondering -- where do the client bits that you use on your SuSE
client systems come from? (I'm not aware of any SuSE client builds)

Thanks.

Comment 2 hwinther 2011-09-19 13:10:48 UTC
Hi,

thank you for looking into this.

In the spacewalk Wiki (https://fedorahosted.org/spacewalk/wiki/RegisteringClients) client packages are linked for opensuse. I simply fetched the srpms and build them against sled11sp1.

Comment 3 Milan Zázrivec 2011-09-19 16:14:37 UTC
I asked somebody from SuSE to take a look at the bug and take over
the bug ownership: 
https://www.redhat.com/archives/spacewalk-devel/2011-September/msg00030.html

Comment 4 Duncan Mac-Vicar P. 2011-09-19 16:43:57 UTC
The problem seems to come from this, which is after zypper executed:

[Fri Sep 16 11:48:01 2011] up2date
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 336, in __run_action
    (status, message, data) = CheckCli.__do_call(method, params, kwargs)
<type 'exceptions.TypeError'>: 'NoneType' object is not iterable

[Fri Sep 16 11:48:01 2011] up2date D: Sending back response ((6,), 'Fatal error in Python code occured', {})

Investigating, problably zypper returns some non zero if there are elements for zypper ps (lsof)

Comment 5 Duncan Mac-Vicar P. 2011-09-20 08:46:13 UTC
Can you attach /var/log/zypper.log on the machine where the errata was installed?

Comment 6 Michael Andres 2011-09-21 08:31:43 UTC
@hwinther: Is your "/usr/sbin/rhn_check" unmodified? We'd expect the CheckCli.__do_call to be on line 333, not 336. Just want to make sure the __do_call method is unmodified (does not accidentally return none).

Could you please send the checksums of these files, so we're sure to look into the same version as you have installed on your client:

  `md5sum /usr/sbin/rhn_check \
          /usr/share/rhn/actions/errata.py \
          /usr/share/rhn/actions/packages.py`

Comment 7 hwinther 2011-09-21 15:16:28 UTC
Created attachment 524227 [details]
up2date log file of Errata Update: sledsp1-libpciaccess0-5103

Comment 8 hwinther 2011-09-21 15:17:48 UTC
Created attachment 524229 [details]
zypper log file of Errata Update: sledsp1-libpciaccess0-5103

Comment 9 hwinther 2011-09-21 15:18:29 UTC
@Duncan Mac-Vicar:
I attached the /var/log/zypper.log and the corresponding up2date log file for one errata appliement.

@Michael Andres:
We are using an unmodified source version 1.5.16-6.9 of the rhn-client-tools and version 0.4-5.1 of zypp-plugin-spacewalk. The checksums are as followed:
b4300cfb0ee578799186376b1a301b21  /usr/sbin/rhn_check
66aa3a12613d4f32e454c8611d8417a8  /usr/share/rhn/actions/errata.py
2576fbe2016411229c07b1d05c73e4fb  /usr/share/rhn/actions/packages.py

Comment 10 hwinther 2011-10-05 09:36:55 UTC
Hi,

I just want to ask, if there is any recent progress on the bug?

Thanks.

Comment 11 Ionuț Arțăriși 2011-10-17 15:33:47 UTC
Hi hwinther,

Still haven't figured out what exactly is causing the issue on your system, but I have some more suggestions.

I notice that the packages.py checksum doesn't match the one we have and also the version of zypp-plugin-spacewalk is different. Can you update zypp-plugin-spacewalk to 0.4-6.1 from one of these repositories? http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.5/

Try and see if that solves the issue. Afterward, you should also try applying this patch to your Server instance in order for SUSE patches to be installed correctly (it's just one line of code):  http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=9da7323af775c288af8dc9c436c3e3da007a509b

The file you want to modify should be /usr/lib64/python/site-packages/spacewalk/server/rhnCapability.py

You might need to do a `spacewalk-service restart` after applying the patch.

Comment 12 hwinther 2011-12-08 14:12:25 UTC
Hi,

we tested the release 0.4-6.2 of zypp-plugin-spacewalk which appears to solve the issue. Thank you very much for your assistance.

Regards