Hide Forgot
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
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