Red Hat Bugzilla – Bug 960989
[sanlock] Provide a command to request the release of a resource currently held by another host/pid
Last modified: 2013-11-21 06:48:38 EST
Description of problem:
Sanlock should provide a way to request the release of a resource currently held by another host.
This feature is currently implemented in the daemon but it's not exposed through the python bindings. A patch has been posted upstream:
As far as the use case is concerned this feature is probably dependent on some previous patches:
9863624 python: return lease version in read_resource
0ce413a python: add the versioning support to acquire
The API call named "request" (for consistency with the name exposed by the C API) is defined as follows:
request(lockspace, resource, disks [, action=REQ_RELEASE, version=0])
The possible values for action are REQ_RELEASE and REQ_FORCE (which escalates to sigkill if the regular graceful release is not satisfied).
how do we test this?
(In reply to Yaniv Eylon from comment #2)
> how do we test this?
Using a shared storage, two hosts and sanlock commands (even better python scripts). We'll add the technical details (e.g. sanlock commands or python scripts) ASAP.
Here is a sequence of commands to test the capability without the need for a separate test program. It uses a shared vg "test" with a shared lv "test".
host1,2: service wdmd start
host1,2: service sanlock start
lvcreate -n test -L1G test
sanlock client init -s test:0:/dev/test/test:0
sanlock client init -r test:test:/dev/test/test:1048576
host1: sanlock client add_lockspace -s test:1:/dev/test/test:0
host2: sanlock client add_lockspace -s test:2:/dev/test/test:0
host1: sanlock client command -r test:test:/dev/test/test:1048576 -c /bin/sleep 1000
(This acquires the lock then runs "sleep" for 1000 seconds.)
host2: sanlock client request -r test:test:/dev/test/test:1048576:2 -f 1
(After this, the "sleep" on host1 should be killed within 30 seconds.)
tested according to instructions in comment #4.
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.