Bug 1397195

Summary: LVM_REPORT_FD output available *after* lvm shell prompt is read
Product: [Fedora] Fedora Reporter: Tony Asleson <tasleson>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: agk, anprice, bmarzins, bmr, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lvm2-2.02.168-1.fc26 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-05 09:05:52 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:

Description Tony Asleson 2016-11-21 21:00:35 UTC 
Description of problem:

When utilizing lvm shell and writing commands to stdin and getting results written to LVM_REPORT_FD, we occasionally get into a situation where we have read 'lvm> ' back on stdout, but nothing exists on the report FD.  It's our expectation that by the time we read the lvm shell prompt back that all output has been written to the LVM_REPORT_FD and other FDs too.  Otherwise we have no indication of when to stop waiting for output.  I have a work around in the lvm dbus daemon where if we have the "lvm>" prompt back and 0 data read on report FD we will take another loop trying to read data from all the FDs with a 2 seconds select timeout.  When I do this we do end up reading the JSON on the report fd.

Version-Release number of selected component (if applicable):

Current upstream, in this specific case: 2a86f54b09312db58b662b1779557466a639567f

How reproducible:
10-20% of the time, appears to be a race condition between when data written to stdout beats the output written on the report fd.


Steps to Reproduce:

The use case where we are seeing this the most is in error cases.  For example the lvm dbus test tries to resize an LV to the same size, which is expected to fail, eg. lvm> lvresize --force -L+0B wkmgtiig_vg/iuavagma_lv
Comment 1 Tony Asleson 2016-12-02 19:32:12 UTC 
After looking at this some more and making a number of changes to test different theories I've settled on the realization that it's not correct to expect time ordering of data written to multiple stream interfaces.  Thus lvm dbus has been modified to handle and accommodate this.


Patched upstream:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=25b5413f895bc61357ef4afab255e3125335d4ec