Bug 1357883

Summary:	libsanlock does not handle EINTR, causing failures in client
Product:	Red Hat Enterprise Linux 7	Reporter:	Jan Kurik <jkurik>
Component:	sanlock	Assignee:	David Teigland <teigland>
Status:	CLOSED ERRATA	QA Contact:	Raz Tamir <ratamir>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.4	CC:	acanan, agk, amureini, bmcclain, cluster-maint, jbrassow, mkalinin, mnavrati, nsoffer, ratamir, salmy, snagar, teigland, ylavi
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sanlock-3.2.4-3.el7_2	Doc Type:	Bug Fix
Doc Text:	Previously, calling libsanlock library functions could fail with the EINTR error if the calling program received a signal while blocked in libsanlock. As a consequence, a failure occurred on the client's side. A patch has been applied to fix this bug, and calling libsanlock functions no longer fails in the described situation.	Story Points:	---
Clone Of:	1356667	Environment:
Last Closed:	2016-11-09 17:15:47 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:	1356667
Bug Blocks:

Description Jan Kurik 2016-07-19 13:18:02 UTC

This bug has been copied from bug #1356667 and has been proposed
to be backported to 7.2 z-stream (EUS).

Comment 3 Nir Soffer 2016-07-19 14:56:43 UTC

Aharon, can you ack this clone?

Comment 4 Nir Soffer 2016-07-19 15:04:45 UTC

David, do we have a build for testing?

Comment 6 David Teigland 2016-07-19 15:42:48 UTC

build is sanlock-3.2.4-3.el7_2

Comment 7 Nir Soffer 2016-07-21 13:51:43 UTC

(In reply to David Teigland from comment #6)
> build is sanlock-3.2.4-3.el7_2

David, is this fix available on Fedora? on which version?

Comment 8 David Teigland 2016-07-21 15:36:10 UTC

f24 and f25

Comment 10 David Teigland 2016-07-25 14:56:27 UTC

I think it's going into 7.2.z.  That's what Nir asked for, and AFAIK it will just happen at some point without any further involvement from me.

Comment 16 Aharon Canan 2016-08-01 11:45:21 UTC

Raz, 

Following our discussion , Please verify .

Comment 17 Yaniv Kaul 2016-08-07 05:35:09 UTC

(In reply to Aharon Canan from comment #16)
> Raz, 
> 
> Following our discussion , Please verify .

Any updates?

Comment 18 Raz Tamir 2016-08-07 20:01:55 UTC

Verified over
# rpm -qa | grep sanlock
sanlock-debuginfo-3.2.4-3.el7_2.x86_64
libvirt-lock-sanlock-1.2.17-13.el7_2.5.x86_64
fence-sanlock-3.2.4-3.el7_2.x86_64
sanlock-lib-3.2.4-3.el7_2.x86_64
sanlock-python-3.2.4-3.el7_2.x86_64
sanlock-3.2.4-3.el7_2.x86_64
sanlock-devel-3.2.4-3.el7_2.x86_64

on engine:
ovirt-engine-4.0.2.4-0.1.el7ev.noarch

Executed our tier 1 and no regressions found

Comment 19 Allon Mureinik 2016-08-08 09:07:57 UTC

Thanks Raz.
David - how soon can we get the RPM released to RHV can depend on it?

Comment 20 Yaniv Lavi 2016-08-08 11:51:27 UTC

We need this fix async urgently. Can you please help with getting this out?

Comment 22 Yaniv Kaul 2016-10-19 15:07:49 UTC

Any news here?

Comment 23 David Teigland 2016-10-19 15:25:21 UTC

moving needinfo back to it's previous value (this left my hands three months ago).

Comment 25 errata-xmlrpc 2016-11-09 17:15:47 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2680.html