Bug 1001982

Summary: Software provider hold yum lock when lmi shell is ended with ctrl+c
Product: Red Hat Enterprise Linux 7 Reporter: Robin Hack <rhack>
Component: openlmi-providersAssignee: Michal Minar <miminar>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: jgrec, psklenar
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-12 10:49:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 922084    

Description Robin Hack 2013-08-28 09:09:47 UTC
Description of problem:


Version-Release number of selected component (if applicable):
openlmi-providers-0.1.1-2.fc20.x86_64

How reproducible:
always

Steps to Reproduce:
1. start lmishell
2. 
> c = connect("localhost", "root", "blank")
> cs = c.root.cimv2.Linux_ComputerSystem.first_instance()
> for identity in cs.associators(Role="System", ResultRole="InstalledSoftware", ResultClass="LMI_SoftwareIdentity"):
...     print(identity.ElementName)
... 
Now press ctrl+c:
^CTraceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/lmi/shell/LMIDecorators.py", line 210, in wrapper
    return fn(self_wr, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/lmi/shell/LMIDecorators.py", line 85, in wrapper
    return fn(self_wr, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/lmi/shell/LMIInstance.py", line 327, in associators
    associators_list = self._conn._client._get_associators(self._cim_instance, **kwargs)
  File "/usr/lib/python2.7/site-packages/lmi/shell/LMIBaseClient.py", line 526, in _get_associators
    return self._cliconn.Associators(instance.path, **params)
  File "/usr/lib/python2.7/site-packages/pywbem/cim_operations.py", line 695, in Associators
    **params)
  File "/usr/lib/python2.7/site-packages/pywbem/cim_operations.py", line 167, in imethodcall
    verify_callback = self.verify_callback)
  File "/usr/lib/python2.7/site-packages/pywbem/cim_http.py", line 217, in wbem_request
    response = h.getresponse()
  File "/usr/lib64/python2.7/httplib.py", line 1045, in getresponse
    response.begin()
  File "/usr/lib64/python2.7/httplib.py", line 409, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline(_MAXLINE + 1)
  File "/usr/lib64/python2.7/socket.py", line 476, in readline
    data = self._sock.recv(self._rbufsize)
  File "/usr/lib64/python2.7/ssl.py", line 241, in recv
    return self.read(buflen)
  File "/usr/lib64/python2.7/ssl.py", line 160, in read
    return self._sslobj.read(len)
KeyboardInterrupt

> ctrl+d

3.
# yum install openlmi-software --enablerepo=rawhide
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Existing lock /var/run/yum.pid: another copy is running as pid 13721.
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: cimprovagt
    Memory : 274 M RSS (1.1 GB VSZ)
    Started: Wed Aug 28 04:36:36 2013 - 23:12 ago
    State  : Running, pid: 13721
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: cimprovagt
    Memory : 274 M RSS (1.1 GB VSZ)
    Started: Wed Aug 28 04:36:36 2013 - 23:14 ago
    State  : Running, pid: 13721


Actual results:
Lock is hold after lmishell ends until request is not finished in cimprovagt.

Expected results:
No locked yum? It's troubles with jobs inside software provider?

Comment 2 Michal Minar 2013-09-12 10:49:44 UTC
This is in fact an expected behaviour. Provider does not have any way how to find out that user doesn't want to wait for completion anymore. When operation, such as enumeration of installed packages, is started, provider has to finish it. Only then the yum lock can be released (if no other operation is running or queued).